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Part 1. APPC, APPN, and HPR 


So how do you choose the right solution for your AS/400 or iSeries server networking needs? There are 
so many different networking schemes, possibilities, and protocols that it may be difficult to decide on the 
best setup for you and your business. 


Systems Network Architecture (SNA) includes the layered logical structure, formats, protocols, and 
operational sequences that are used for transmitting information units through networks. One example of 
implementing SNA to connect the AS/400 or iSeries server with other systems, to connect remote 
controllers, and to maintain a high-level of security on your system is through the use of APPC, APPN, and 
HPR. 


If using APPC, APPN, and HPR sounds like a possibility, review the following pages: 


Planning your APPN and HPR network 
Configuring APPC, APPN, and HPR 


APPC, APPN, and HPR configuration examples 


Many factors can affect the performance of the AS/400 or iSeries server in a communications environment. 


To achieve optimal performance with your particular communications environment, review the |Optimizing 
AAPPN and HPR communication performance] page. 


Finally, see the|APPC, APPN, and HPR security considerations] page for information to help keep your 


APPN environment secure. 


Communication problems are inevitable and will probably be an issue as you manage your network. If you 
suspect that you are having communication problems while running APPC, APPN, and HPR, see the page 
Troubleshooting APPN and HPR|to help in finding solutions. 

If you would like more information on APPC, see the following book: 


— fi 
¢ |APPC Programming] “= 


Code disclaimer information 
This document contains programming examples. 


IBM grants you a nonexclusive copyright license to use all programming code examples from 
which you can generate similar function tailored to your own specific needs. 


All sample code is provided by IBM for illustrative purposes only. These examples have not been 
thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, 
serviceability, or function of these programs. 


All programs contained herein are provided to you "AS IS” without any warranties of any kind. The 
implied warranties of non-infringement, merchantability and fitness for a particular purpose are 
expressly disclaimed. 
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Chapter 1. Print this topic 
To view or download the PDF version, select|APPC, APPN, and HPR|(about 604 KB or 136 pages). 


Saving PDF files 


To save a PDF on your workstation for viewing or printing: 

1. Right-click the PDF in your browser (right-click the link above). 

2. Click Save Target As... 

3. Navigate to the directory in which you would like to save the PDF. 
4. Click Save. 


Downloading Adobe Acrobat Reader 


If you need Adobe Acrobat Reader to view or print these PDFs, you can download a copy from the 


(www.adobe.com/products/acrobat/readstep. html) : 
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Chapter 2. Plan your APPN and HPR network 


After you have decided to implement APPN and HPR for your network, there are a few points you may 
want to keep in mind before setting up and configuring [Selecting your APPC networking pratocelicives 
ou some operational characteristics to think about when choosing your protocol. In addition, the page 

Designing an APPN and HPR network discusces some design theories to consider for optimal 


communication performance. 


Select your APPC networking protocol 


When choosing the advanced program-to-program communications (APPC) networking protocol for your 
business, you should understand some of the operational characteristics for APPN and HPR. These 
operational characteristics may affect communication performance on your system. 


Note: While you can run APPC without using APPN or HPR, it may be advantageous to use APPN or 
HPR since they require less configuration than running pure APPC for your applications. 


To help you choose your APPC networking protocol, consider the following: 

* HPR provides a significant enhancement in terms of network availability by establishing and maintaining 
end-to-end connections and the ability to switch paths transparently. Segmentation and reassembly are 
accomplished in the central processing unit (CPU). For APPN, the segmentation and reassembly 
happen in the input/output processor (IOP). This capability of being able to transparently switch paths 
comes with additional central processing (CPU) usage as compared to APPN. 

¢ The choice of which protocol to use really comes down to deciding whether the high availability features 
of HPR are desirable in your environment. When determining whether to use APPN or HPR, you should 
consider the following: 

— The high-availability feature of HPR 
— The feasibility of higher CPU usage for your environment 


You can control the selection of APPN or HPR easily by manipulating the network attributes. It is just as 
simple to change from HPR to APPN as it is to change from APPN to HPR. The best way to determine the 
affect of using HPR and APPN in your environment would be to perform some of your own benchmarks. 


Design an APPN and HPR network to optimize communications 
performance 


The following list is a selection of tasks that are aimed at getting better performance from a network. 


To optimize performance when designing your network, consider the following: 
¢ Avoid mesh connectivity 


The number of control program-to-control program (CP-CP) sessions that are configured for each 
network node (NN) has a direct impact on the performance of a network. Network control information 
such as topology updates and location searches flow over CP-CP sessions. A consequence of too many 
CP-CP sessions is that information is sent out to more nodes and the same node multiple times. This 
increases the network processing that is done. In a mesh-connected network, every NN has a CP-CP 
session with every other NN, increasing the number of CP sessions in this network. The number of 
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CP-CP sessions in the network should be kept to a minimum while still providing necessary connectivity. 


Rid T20e-0 


Consider backup CP-CP sessions where appropriate 


A CP-CP spanning tree is a term that is used to describe the contiguous path of CP-CP sessions 
between nodes throughout the network. CP-CP sessions carry necessary control information and are 
required between NNs in order to participate in the APPN network. Careful analysis to determine the 
minimal set of links, that support CP-CP sessions, is important. Once these links are identified, it is 
recommended that back-up links providing alternate CP-CP sessions are added to the network. These 
backup links ensure availability of the CP-CP spanning tree and are needed if the critical links fail. 
Consider using border nodes 


APPN architecture does not allow two adjacent APPN NNs to connect and establish CP-CP sessions 
when they do not share the same network identifier (NETID). Border nodes overcome this restriction. 
Border nodes enable NNs with different NETIDs to connect and allow session establishment between 
logical units (LU) in different NETID subnetworks. Border nodes prevent topology information from 
flowing across different NETID subnetworks. Use border nodes to subdivide a large APPN network into 
smaller and more manageable subnetworks. iSeries provides this border node capability for only 
adjacent networks. 

Processing reduction for an EN and low-entry networking (LEN) node 


The amount of processing is reduced when the iSeries is an end node or LEN node, as opposed to an 
NN for the following reasons: 

— All network topology, and directory search information flows to every attached network node. 

— End nodes and LEN nodes do not receive most of these information flows. 


The network nodes (NN) perform route calculation for themselves and other ENs and LEN nodes. (This 
function flows from the EN or LEN node to the NN.) 
Reduction of network flows resulting from fewer network nodes 


In addition, topology information about ENs and LEN nodes does not flow through the network. NN 
topology does flow to the entire network that causes the other network nodes to process information 
about every other network node. 

Use Branch Extender 

Branch Extender is an extension to the APPN network architecture. It appears as a network node (NN) 
to the Local Area Network (LAN), and as an end node (EN) to the Wide Area Network (WAN). This 
reduces topology flows about resources in the LAN from being disconnected from the WAN. The only 
topology flows necessary are for network management that identify the types of links. 


For more information about setting up Branch Extender, see the page|Changing network attributes 


For help in getting optimal performance from you network, see the page|Optimizing APPN and HPR 
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Chapter 3. Configure APPC, APPN, and HPR 


You can configure APPC, APPN, and HPR on your system automatically or manually. To understand how 
APPN and HPR automatically configure controller descriptions on a LAN, refer to the page 


configuration on LANs} To manually configure this support, see}/Manual configuration 


Branch Extender is an extension to the APPN network architecture. It appears as a network node (NN) to 


the Local Area Network (LAN), and as an end node (EN) to the Wide Area Network (WAN). See 
Configuring Branch Extender support|for information on how to configure and take advantage of this 


feature. 


A connection network is a switched network (such as a local area network, X.25, or public-switched dial 
network) that allows a local node to establish APPN connections to more than one undefined adjacent 


node. For more details, see|Connection network support 


The way your system is configured makes a significant difference in the performance of it during 
communications error recovery. See|Configuration considerations used to optimize error recovery 
performance}for more information. 


If you would like to connect personal computers to the iSeries server, see the page|Connecting a PC to 
iSeries 400 using Personal Communications 


Finally, |Configuring APPC with VTAM|will give you some helpful information on coordinating Virtual 
Telecommunications Access Method (VTAM) and advanced program-to-program communication (APPC) 


configuration objects. 
Note: Read the|code disclaimer information|for important legal information. 


Automatic configuration on LANs 


Automatic configuration support for LANs allows the iSeries server to accept incoming calls from node type 
2.1 systems (for example, iSeries servers and personal computers). This can only be supported if a 
controller description is not varied on that has a matching LAN address of the calling system. The system 


can be told which to use for the controller descriptions that get automatically created and 
varied on. If the line has been defined to allow latiornaile leation of contoller deseristionsl then the 
system creates and varies on an APPC controller description that specifies APPN(*YES). This support 
allows for automatic creation, automatic vary on, of these APPC controller 
descriptions, and their attached device descriptions. 

Notes: 


1. An operator may vary on, vary off, or delete automatically created controller descriptions. 
2. Only APPC controller descriptions automatically configure on a LAN. 


If you are using model controller descriptions see the page, |Communication considerations using model 
eorlerd 


For more information, see|Controlling automatic configuration 


Determine parameters during automatic configuration 


The system can be told which parameters should be used for the controller descriptions that get 
automatically created and varied on. If a model controller description does not exist for a line that supports 
automatic configuration, then the automatically created, or varied on controller descriptions use the 
system-supplied defaults for the various parameters. There are two types of parameters that are specified 
in the automatically configured controller descriptions: 

* Those found during the automatic configuration 
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¢ Those specified in the model controller or in the system-supplied defaults 


Those found during automatic configuration do not use the values that are specified in the model controller 
or any system values. They are found when the adjacent system on the LAN calls the iSeries system and 
then participates in a swapping of exchange station IDs (XID). A description of these parameters are as 
follows: 
RMTNETID 
Remote network identifier. 
RMTCPNAME 
Remote control-point name. 
ADPTADR 
LAN adapter address of the remote system. 
SSAP_ Source service access point for the connection. 
DSAP Destination service access point for the connection. 
NODETYPE 
Set to *LENNODE if the remote system does not supply a control-point name on its XID. 
Otherwise, it is set to *CALC. 
TMSGRPNBR 
Set to *CALC since the system negotiates this value with the adjacent node. 
CPSSN 
Set to *NO if the NODETYPE parameter in the automatically configured controller gets set to 
“LENNODE. Otherwise, it is set to *YES. The system determines if it needs to establish a CP-CP 
session with the adjacent node. This is determined based on the network server list (if the local 
system is an end node), or the adjacent system’s request for CP session services. 
SWTLINLST 
Set to the token ring, Ethernet, DDI, or WLS line the call was received on. For automatically 
configured controller descriptions, there is only one line that is listed in the SWTLINLST. The 
system may change this parameter for automatically configured controllers that already exist. 


The other parameters in the automatically created controller descriptions are copied from the model 
controller description (if the model controller associated with the line that the call was received on is varied 
on), or are system-supplied defaults. An exception to using system-supplied defaults is the ONLINE 
parameter. It is set to “NO for automatically configured controller descriptions since various systems may 
be automatically configured (such as personal computers, iSeries systems, and System/36s), and you may 
not want all systems varied on at initial program load (IPL). 


APPC controllers that are automatically created on a LAN have the CTLOWN (control owner) parameter 
set to *SYS since the system controls that controller description. If an operator wishes to change any 
parameters in a controller that was created automatically, the CTLOWN parameter needs to be set to 
*USER. By setting this parameter to “USER, the system does not automatically vary on, change, or delete 
this controller description. The operator now owns this controller description. 


Automatic creation and vary on of the controller description 


When APPN support determines that it needs a controller description automatically varied on, it determines 
if there are any existing controller descriptions that follow the naming convention for automatically created 
APPC controllers. 


Naming convention for controller descriptions: 
¢ The first controller description created has the same name as the CP name of the adjacent system 
¢ Additional controller descriptions created use the following conventions: 
CPNAMExx 
Where CPNAME is the adjacent system’s control-point name and xx is some value from 00-FF. 


If the adjacent system does not send a control-point name, then the local system creates a name that is 
based on the adjacent system’s EXCHID value. The format of the name is: 
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Cilllixx 


Where C is a constant value, Illll is the exchange identifier (that is not including the three-digit 
block number), and xx is some value from ’00-FF’. 


For an existing controller description to be considered a possible candidate for being automatically varied 
on, it must: 


Satisfy the naming convention 

Be an APPC controller description 

Be in a varied off status 

Have RMTCPNAME and RMTNETID parameters that match the incoming XID parameter 
Have LINKTYPE parameter specified as *LAN. 


If no controllers are found that meet these initial requirements for automatic vary on, then the system 
creates a new controller. The name of this controller will be the first available name that follows the 
naming convention for this remote control-point name, and the controller description will indicate that the 
controller owner is the system (CTLOWN(*SYS)). 


Automatic vary off and deletion of controller descriptions 


The automatic vary off and delete function is controlled by the AUTODLTCTL parameter in the line 
description. When a controller description that specifies CTLOWN(*SYS) is varied on manually or 
automatically: 


The system copies the current value of the AUTODLTCTL parameter associated with the controller 
description. 

When a controller goes to a vary on pending status, a timer based on the AUTODLTCTL parameter is 
started. If this controller remains in a vary on pending status, and it is not varied off manually by the 
operator for the entire time specified by the AUTODLTCTL parameter, then the system automatically 
varies off and deletes the controller description and all of its attached APPN device descriptions. 


For more information on this page, see |Considerations for the automatic deletion of APPC controller 


descriptions on the LAN 


Communication considerations using model controllers 
When MDLCTL(*YES) is specified, it is treated differently than other APPC controller descriptions. 


The following are some considerations for model controller descriptions: 


Device descriptions cannot be attached to model controllers. 

Model controllers only go to a status of varied on. 

A model controller can be associated with only one line description at a time. This configuration is done 
using the SWTLINLST parameter in the model controller. 

The RMTNETID, RMTCPNAME, and ADPTADR parameters are optional parameters when 
MDLCTL(*YES) is specified. 


Note: When a communications session is requested and the local system is an end node, the adjacent 
system must be specified in the NETSERVER parameter of the CHGNETA command in order for 
the local system to establish CP-CP sessions with the adjacent system. 

Since model controller descriptions do not represent an actual connection, they are not associated with 

a line description when using the Work with Configuration Status (WRKCFGSTS) command. 


To configure a model controller description, specify MDLCTL(*YES) in an APPC controller description. 


Control automatic configuration 


You control automatic configuration by the AUTOCRTCTL parameter in the token ring, Ethernet, DDI, or 
WLS line descriptions. This parameter can be changed at any time. It is not necessary to vary off 
controllers that are attached to these line descriptions before changing the AUTOCRTCTL parameter to 
“YES or *NO. 
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Automatic configuration is controlled on a line-by-line basis. That is, one line may specify 
AUTOCRTCTL(*YES) and another line may specify AUTOCRTCTL(*NO). The automatic configuration 
support for LANs is not related to the QAUTOCFG system value. The setting of QAUTOCFG has no effect 
on this support. 


Note: When you are running APPC over TCP/IP, there is no line that is directly associated with the APPC 
controller. Therefore, the APPC over TCP/IP controllers LINKTYPE (*ANYNW) must be manually 
created. 


Manual configuration for APPN and HPR 


Network attributes describe the local system name, the default local location name, the default control 
point name, the local network identifier, and the network node type. They also determine whether the 


system uses HPR, or whether you want to use virtual controllers for APPN. Assuming you have alread 
properly configured an advanced program-to-program communications (APPC) environment, 
network attributes] would be your first step in configuring APPN and HPR. 


The following are some other steps you may need to perform during your configuration process: 

* Define lines with fire descrptone| Deparcinc on your hardware, the lines may be attached to a network 
server, or a network interface. 

* Define controllers with Controller descriptions are attached to lines. 

* Define devices or locations with Device descriptions are attached to controllers. 

“Create APPN location lists” on page 13 

“Create mode descriptions” on page 13 

“Create a class-of-service description” on page 13 


Change network attributes 


Network attributes describe the local system name, the default local location name, the default control 
point name, the local network identifier, and the network node type. If the machine is an end-node, the 
attributes also contain the names of the network servers that are used by this iSeries system. Network 
attributes also determine whether the system uses HPR, or whether you want to use virtual controllers for 
APPN. 


To change the network attributes, do the following: 
1. Vary off all APPC and host controllers. The easiest way to do this is to use: 


VRYCFG CFGOBJ(*APPN) CFGTYPE(*CTL) 
STATUS (*OFF) RANGE (*NET) 


Note: When using automatic creation of controllers on LANs and you vary off the controllers, you have 
approximately 2 minutes before the iSeries automatically varies on the controllers again. If you 
have many configuration objects, temporarily turn off APPN auto-creation on the LAN line by 
using the command CHGLINxxx AUTOCRTCTL(*NO), where xxx is TRN, ETH, DDI, or WLS. 
When you have changed the necessary network attribute, use the command CHGLINxxx 
AUTOCRTCTL(*YES) to resume normal APPN function. 

2. Type the Change Network Attributes (CHGNETA) command on any iSeries command line and press 
F4, 

Use the online help information to complete the parameter values. 

Press the Enter key. The network attributes are changed. 

Vary on all the controllers that were varied off in the first step. Use: 


VRYCFG CFGOBJ(*PRVCFGTYPE) CFGTYPE(*CTL) 
STATUS (*0N) RANGE (*NET) 


le 


Note: The VRYCFG of *APPN will find all APPN controllers and devices on the system and will try to vary 
them off. The VRYCFG with *PRVCFGTYPE will then try to vary them all on. 
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Configuring APPN virtual controllers 


On the iSeries, local applications that need to establish LU 6.2 sessions to other locations in the APPN 
network require an APPC device description that specifies APPN(*YES). For simplicity, these devices are 
referred to as APPN devices. Multiple device descriptions can be created and used simultaneously to 
communicate between the same local location and the remote location pair. After a session is established, 
the controller description continues to use the same APPN device description for the life of that session. 


To configure virtual controllers, do the following: 
¢ Set the ALWVRTAPPN network attribute to (*YES) 


After this is done, existing APPN device descriptions (attached to a real controller description) will no 
longer be used. 


If you do not want to use virtual APPN support: 
1. Vary off the attached controller 

2. Change the ALWVRTAPPN network attribute 

3. Vary the controller back on 


The APPN device can now be varied on. 
Note: This does not affect HPR since it always uses virtual APPN support. 


If you are using the HPR tower option (RTP): 
1. Vary off all APPN controllers. Use: 
VRYCFG CFGOBJ(*APPN) CFGTYPE(*CTL) 
STATUS (*OFF) RANGE (*NET) 
2. Set the Allow HPR transport tower support (ALWHPRTWR) parameter to (“YES) 
3. Vary on all your APPN controllers. Use: 


VRYCFG CFGOBJ(*PRVCFGTYPE) CFGTYPE(*CTL) 
STATUS (*0N) RANGE (*NET) 


Configuring APPN using Branch Extender 


To use Branch Extender, see the page |Configuring Branch Extender support. 


For more information about Branch Extender, see the page |Designing an APPN and HPR network to 
optimize communications performance 


Considerations for system names 


Use caution when you use names with the special characters # (X’7B’), $ (‘5B’), and @ (’7C’). These 
special characters might not be on the keyboard of the remote system. These special characters are not 
supported for APPC over TCP/IP (network IDs and location names only). The use of these symbols should 
be limited to migration of the operating system. Do not use these characters for newly created names. 


If you are using a national language keyboard that does not have the #, $, or @ symbols, see the 


appendix on national language keyboard types and the appendix on code pages in the|national language 
Ikeyboare! types 


eyboard types} topic in the Information Center. 


The names that may be exchanged with remote systems include the following: 
¢ Network IDs 

¢ Location names 

¢ Mode names 

* Class-of-service names 

* Control-point names 

* Connection network names 
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Create an APPC controller description 


A controller description defines the adjacent systems in the network. 

¢ The use of Advanced Peer-to-Peer Networking (APPN) support is indicated by specifying APPN(*YES) 
when creating the controller description. 

* The use of high-performance routing (HPR) support is indicated by specifying HPR(*YES) when creating 
the controller description. 


To create controller descriptions, do the following: 
1. Type one of these commands on any iSeries command line for the type of controller you need to 
define and press F4. 
* Create Controller Description (APPC) (CRTCTLAPPC) 
* Create Controller Description (Systems Network Architecture (SNA) HOST) (CRTCTLHOST) 
2. Use the online help information to choose the correct parameter values. 
3. Press Enter. The controller description is created. 


Note: An APPC controller description is automatically created when the following is true: 

¢ The AUTOCRTCTL parameter on a token-ring, Ethernet, wireless, or distributed data interface (DDI) line 
description is set to *YES. 

* The system receives a session start request over the line from a system without an existing controller. 


To specify AnyNet support, you must specify *ANYNW on the LINKTYPE parameter of the CRTCTLAPPC 
command. 


Create device descriptions for APPC connections 


A device description for APPC connections describes the characteristics of the physical or program device 
that is to communicate with the local system. Device descriptions can describe a physical device (Such as 
an Advanced Function Printing device) or logically represent a communications session or a program 
running on another system. 


Note: The device description is usually created after the controller description. Device descriptions for 
Advanced Peer-to-Peer Networking (APPN), Transmission Control Protocol/Internet Protocol 
(TCP/IP), Internetwork Packet Exchange (IPX), and user-defined communications are usually 
created automatically. When the Create Device Description (APPC) command is used to create 
APPN devices, the APPN parameter must be set to *YES. 


The system automatically creates devices for APPN communications. However, other device types are 
valid for APPC and APPN. 


If you need to create a device description, do the following: 
1. Type one of these commands on the iSeries command line for the type of device you are creating and 
press F4: 
* Create Device Description (APPC) (CRTDEVAPPC) 
* Create Device Description (Display) (CRTDEVDSP) 
* Create Device Description (Host) (CRTDEVHOST) 
* Create Device Description (Printer) (CRTDEVPRT) 
* Create Device Description (SNA Pass-through) (SNPT)) (CRTDEVSNPT) 
* Create Device Description (SNA upline facility (GNUF)) (CRTDEVSNUF) 
2. Use the online help information to choose the parameter values. 
3. Press Enter. The device description is created. 
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Create APPN location lists 


APPN locations define special characteristics of remote locations for APPN. Special characteristics of 
remote locations include whether the remote location is in a different network from the local location and 
security requirements for both. If special characteristics of remote locations exist, an APPN remote location 
list is required. 


One local location name is the control point name that is specified in the network attributes. If you need 
additional locations for the iSeries system, an APPN local location list is required. 


Note: QAPPNSSN and QAPPNDIR are two special configuration lists that can be manually configured to 
—+make your system secure. 


To create APPN location lists, do the following: 

1. Type the Create Configuration List (CRTCFGL) command on any iSeries command line and Press F4. 
2. Specify *APPNLCL for the configuration list type (Type parameter). 

3. Use the online help information to choose the correct parameter values. 

4. Press Enter. The APPN location list is created. 


Create mode descriptions 


Mode descriptions describe the session characteristics (including the number of sessions) that are used to 
negotiate the allowable values between the local and remote locations. The iSeries mode descriptions are 
used only by APPC, APPN, and HPR support. 


Note: The system ships with several mode descriptions. You probably will not need to create one. You 
can use the Work with Mode Descriptions (WRKMODD) command to find out which mode 
descriptions already exist on your system. 


The mode description also specifies a Class-of-Server Description (COSD) that is used if and when this 
mode is used to cross an APPN network. 


If you need to create a mode description, do the following: 

1. Type the Create Mode Description (CRTMODD) command on any iSeries command line and press F4. 
2. Use the online help information to choose the parameter values. 

3. Press Enter. The mode description is created. 


In order for APPN and HPR to choose an optimal route at any given point in time, the pre-established 
sessions and locally controlled parameters should be set to zero. 


Notes: 

1. If pre-established sessions are not set to zero, the first time the mode is started (through session 
establishment or by using the STRMOD command) APPN and HPR will establish the number of 
sessions specified. These sessions remain up even if conversations are not active. 

2. If locally controlled sessions are not set to zero, (through session establishment, or by using the 
STRMOD command) APPN and HPR establish one session that will not be taken down upon 
conversation end. 


Create a class-of-service description 


A class-of-service description tells the system which network nodes and transmission groups are 
acceptable and, of those acceptable, which are preferred during route selection. The descriptions can 
include information such as transmission priority, link speed, cost-per-connection time, and security. 
Class-of-service descriptions are used only by APPN and HPR. 


To create a Class-of-service description, do the following: 
1. Type the Create Class-of-Service Description (CRTCOSD) command on any iSeries command line and 
press F4. 
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2. Use the online help information to choose the parameter values. 
3. Press Enter. The class-of-service description is created. 


Configure Branch Extender support 


Branch Extender is an extension to the APPN network architecture that appears as a network node (NN) 
to the Local Area Network (LAN), and as an end node (EN) to the Wide Area Network (WAN). This 
reduces topology flows about resources in the LAN from being disconnected from the WAN. The only 
topology flows necessary are for network management identifying the types of links. 


To configure Branch Extender: 

1. Set the NODETYPE parameter in the network attribute to *~BEXNODE 

2. Set the BEXROLE controller parameter. This specifies the role of the local system in an APPN network 
for the remote controller being configured. The two options for BEXROLE are: 
¢ *NETNODE: The local system takes the role of a network node for the remote controller. 
* *“ENDNODE: The local system takes the role of an end node for the remote controller. 


Connection network support 


A connection network allows APPN support to find addressing information about another system on a LAN 

when a connection needs to be established. The connection network is an enhancement of automatic 

configuration since the iSeries system determines addressing information for outgoing calls and 

automatically creates the associated controller description. Without connection network support, one of the 

two systems making a connection would be required to have the other system’s LAN address and other 

controller information manually configured. The main benefits for using connection network support are: 

¢ It requires less manual definition of controller descriptions. 

* It provides direct, any-to-any connectivity with other systems that are defined to the same connection 
network instead of using intermediate routing. 

¢ It reduces the amount of information in the APPN topology database and decreases the number of 
topology updates sent to other systems. 


For information on how to take part in a connection network see}Requirements to participate in a 


The page, |Connection network configuration considerations| gives you some points to 


keep in mind when configuring your connection network. 


Requirements for an APPN connection network 


To participate in an APPN connection network, a system needs to have a CP-CP session established with 

a network node and a model controller description configured. Other points to consider: 

¢ A System/36 does not support connection networks, so an iSeries end node that wants to participate in 
a connection network must not have a System/36 listed as a possible server in its network server list. 
Requirements to define this connection network are: 

— Supply the connection network identifier (C NNNETID) and connection network control-point name 
(CNNCPNAME) in the model controller description that is associated with the token ring, or Ethernet 
line description. 

— All systems connected to the same LAN (that want to participate in the connection network) must 
specify the same value for their CNNNETID and CNNCPNAME parameters. 

* For a connection network defined on a LAN, the local address that is used is a combination of the LAN 
adapter address (taken from the token ring or Ethernet line description) and the source service access 
point (SSAP) (taken from the model controller description that describes the connection network). 

* Network nodes have the ability to establish CP-CP sessions that are initiated by other nodes on the 
LAN. The destination systems with which CP-CP sessions need to be established can be supplied in 
the model controller description by specifying the RMTNETID, RMTCPNAME, and ADPTADR 
parameters. 
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Connection network configuration considerations 


Following are two examples showing incorrect configuration of a connection network. The correct 

configuration of the same example follows: 

¢ Parallel TGs to the same connection network are not allowed. Only one LAN line description may be 
associated with a connection name. 


RvsS126-0 


Figure 1. Incorrect configuration showing parallel TGs to a connection network 


* There can be only one connection network name that is associated with a LAN line description at any 
given time. 


One iSeries system (SYSA) has two LAN line descriptions (with a separate connection network that is 
defined on each), and another iSeries system (SYSB) has two connection network names defined on 
one LAN line. If SYSA were to request multiple sessions to SYSB, the first session may go over CN1. 
Another session initiation request could choose CN2. However, the destination address is the same, so 
the second controller description could not be varied on. 


RAvsSi29-0 


Figure 2. Incorrect configuration showing two connection networks on the same line 


¢ Multiple connection networks (that have different connection network names) may be defined on 
separate LAN lines. 


Rv SS130-0 


Figure 3. Correct configuration showing two connection networks and two LAN lines 
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Note: The name of a virtual node cannot be the same as the control-point name of any network node, or 
end node. That is, the CNNNETID and CNNCPNAME parameters cannot be the same as the 
RMTNETID and RMTCPNAME parameters in any controller descriptions in the entire APPN 
network. 


Configuration considerations used to optimize error recovery 
performance 


How your system is configured makes a significant difference in the performance of it during 
communications error recovery. 


The following are links to communications configuration considerations that may have a significant effect 
on_error recovery. 
“General configuration considerations for improved error recovery performance” 


“Considerations for communications-related system values” on page 17 


“Considerations for network attributes that can affect APPC error recovery” on page 18 


“Considerations for line configuration settings that can affect error recovery” on page 18 
“Considerations for controller configuration descriptions that can affect error recovery” on page 20 
“Considerations for modes that can affect error recovery” on page 23 


“Considerations for jobs that can affect error recovery” on page 23 


See the following references for more detail: 


¢ For advanced configuration pages, see the|Communications Configuration cc book. 
¢ For more information about iSeries communications, see the}Communications Management eS book. 


General configuration considerations for improved error recovery 
performance 


Careful use of the ONLINE general configuration parameter is necessary to avoid unnecessary 
communications error recovery. Most communications configuration objects are created with the ONLINE 
parameter default set to “YES (except for PPP lines, the ONLINE parameter is set to *NO). Consider the 
setting of the ONLINE parameter in any of the following: 

* CRTCTLxxx commands 

* CRTDEVxxx commands 

¢ CRTLINxxx commands 

¢ CRTNWIxxx commands 

* CRTINWSD command 


Note: For the network server (NWS) command, you should set the ONLINE parameter value to *NO. If 
network server descriptions are brought online during the system initial program load (IPL), 
important system jobs could be held up and unavailable for other work. 


When choosing how to set the ONLINE parameter, consider the following: 

* Limit the configuration objects that vary on during IPL with the ONLINE parameter set to *YES. These 
objects should be only those like tape drives, CD-ROM drives, and selected local workstations that are 
critical to getting your applications up and available for general system use. 

* Place critical users in a subsystem group, and vary on configuration objects for this group by using the 
ONLINE parameter that is set to *YES. This allows critical users to get back online sooner. 

¢ For noncritical users, vary on configuration objects at a later point by setting the ONLINE parameter to 
“NO. Use a CL program or change the system startup program to manage vary on of the remaining 
configuration objects. 
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* For controllers on local area networks (LAN), set the auto-configuration parameter (AUTOCRTCTL) to 
“YES on the appropriate LAN controller descriptions. Let the system vary these controller descriptions 
on as needed. 

¢ Whenever possible, avoid varying on any configuration that would fail in attempts to connect to remote 
systems. For example, avoid varying on controllers with a link type of *LAN that have an initial 
connection of *DIAL, when remote systems are not available. Personal computers on local area 
networks (LANs) typically do not respond to connection attempts. 


See the following references for more detail: 


¢ For advanced configuration pages, see the |Communications Configuration Y book. 


¢ For more information about iSeries communications, see the}Communications Management book. 


Considerations for communications-related system values 


System values, such as system date and library list, control information for the operation of certain parts 
of the system. You can change the system value to define your working environment. 


The following information explains more about each of the system values for communications error 

recovery. 

* QCMNARB (communications arbiters): controls the number of communication arbiter system jobs that 
are available to process communications functions. 

— Do not set this value to zero unless directed by software service. If this system value is set to zero, 
the work is performed in the QSYSARB and QLUS system jobs as opposed to being performed by 
the communication arbiters. 

— The QCMNARB system value supports the following values: “CALC, 0-99. 

— *CALC is the default setting for this system value. The system determines the number of jobs based 
on the system’s HW configuration. 

— Consider having more than one QCMNARB job if there is an excessive amount of these system 
activities. 

A change to this value requires an initial program load (IPL) of the system for it to take affect. 
° QPASTHRSVR (pass-through servers): controls how many pass-through server jobs are available for 
processing display station pass-through requests. 

— The default setting of this system value is calculated based on the hardware configuration of your 
system. 

— Consider multiple pass-through server jobs in error recovery situations to make the system quicker. 


Note: Setting the QPASTHRSVR value to 0 is not recommended. The QPASTHRSVR value of 0 is 
intended for use in migrating from the use of communications jobs for the 5250 target display 
station pass-through function to use the pass-through server jobs. 

* QCMNRCYLMT (communications recovery limit): controls the number of automatic recovery attempts to 
make. It also controls when an inquiry message is sent to the system operator when the specified 
number of recovery attempts has been reached. 

— If the CMNRCYLMT parameter value is specified as *SYSVAL for a network interface description, a 

line description, or a controller description, then the QCMNRCYLMT value is also used. These 
parameter values also contain a count limit and time interval. 


The count limit can be 0 (no recovery attempted) to 99. The time interval can be 0, or a value from 1 
to 120 (minutes). A count limit of 0, and a time interval of more than 0 effectively disables automatic 
second-level error recovery. This may cause the devices and controllers to go into recovery pending 
(RCYPND) state, and require operator intervention. A count limit of more than 0, and a time interval 
of 0 allows automatic second-level error recovery continuously. However, this is not recommended. 


Note: To avoid looping recovery, keep the number of retries small; you do not want time to expire 
before the number of retries are exceeded. Otherwise, you will end up in infinite recovery. 
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* QDEVRCYACN (device I/O recovery action): Controls the recovery action to take for the job when a 
device error is encountered on a reading and writing operation on the *REQUESTER device for 
interactive jobs. 


* For more information about iSeries communications, see the|Communications Management] and 


Management{ books. 
at. 
¢ For more information on pass-through server jobs, see the|Remote Work Station Support book. 


Considerations for network attributes that can affect APPC error 
recovery 


Network attributes control information about the communications environment. Allow APPN virtual 
controller support (ALWVRTAPPN), and virtual controller autocreate APPC device limit (VRTAUTODEV) 
are network attributes that play a role when a communications error occurs. 


The following information explains more about each network attribute and how the attribute affects system 
performance during error recovery. 
¢ Allow APPN virtual controller support (ALWVRTAPPN) controls whether APPN devices should be 
attached to real APPN controllers, or to a virtual controller. 
— The default value is *NO. 
— Use virtual APPN controllers to limit the number of devices that go into error recovery when a failure 
occurs. 
— May be used to eliminate multiple device descriptions that can get created when multiple routes 
through the APPN network exist. 
* Virtual controller autocreate APPC device limit (VRTAUTODEV) indicates the maximum number of 
automatically created APPC devices for each virtual controller when the following is true: 
— The Allow APPN Virtual Controller (ALWVRTAPPN) network attribute is *YES. 
— The Allow HPR Transport Tower (ALWHPRTWR) network attribute is *YES. 


The VRTAUTODEV network attribute specifies the upper limit for the number of automatically created 
APPC devices on virtual controllers. The more APPC devices created, the longer it takes the system to 
do error recovery processing on the controller. The default value on this network attribute is 100. For 
every 100 new APPN locations that your system communicates, a new virtual APPN controller is 
created. 


Note: Manually created devices may still be created if the VRTAUTODEV parameter value is less than 
the limit of 254. 


For more information about these system values, see the following books: 
* For more information about iSeries communications, see the|Communications Management| and 
books. 


Considerations for line configuration settings that can affect error 
recovery 
The following line configuration options can affect system performance during error recovery. 


¢ AUTOCRTCTL(*NO, *YES), see|“Considerations for the automatic creation of APPC controlle 


descriptions on the LAN” on page 19 


* AUTODLTCTL(1440), see}|“Considerations for the automatic deletion of APPC controller descriptions on 
the LAN” on page 19 


e Link-level timers and retries 


The configuration of link-level timers and retries can have a significant affect on network performance. 
For a complete list of link-level timers and retries, see the appropriate protocol-specific publication. 
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Considerations for the automatic creation of APPC controller descriptions on the 
LAN 

The automatic creation of advanced program-to-program communications (APPC) controller and device 
descriptions is done in the communications arbiters (QOMNARBxx) jobs. Consider changing these default 
parameters based on your environment and potential error recovery considerations. 


When the APPC controller is automatically configured by default, the system sets these values in the 
APPC controller description: 

¢ Set the ONLINE parameter to *NO. 

* Set the INLCNN parameter to *DIAL. 

* Set the DIALINIT parameter to *LINKTYPE. 

¢ Set the APPN parameter to *YES. 

¢ Set the SWTDSC parameter to *YES. 

* Set the MINSWTSTS parameter to *VRYONPND. 

* Set the AUTODLTDEV parameter to 1440. 


Note: The default settings above may not be desirable for your network. If this is the case, consider 
using a model controller and change these parameter values if you find unnecessary recovery 
attempts. 


When configuring your LAN, use the AUTOCRTCTL parameter on the following commands: 
* CHGLINDDI 

* CHGLINETH 

¢ CHGLINTRN 

* CHGLINWLS 

¢ CRTLINDDI 

¢ CRTLINETH 

¢ CRTLINTRN 

¢ CRTLINWLS 


Note: The AUTOCRTCTL function finds and varies on existing APPN controller descriptions if a matching 
one is found. Thus, you can use the AUTOCRTCTL function to eliminate the need to vary on the 
configuration objects at initial program load (IPL) time. The system varies them on as needed. 


See the following references for more detail: 
¢ For advanced configuration pages, see the |Communications Configuration book. 


it. 
* For more information about iSeries communications, see the}Communications Management| book. 


¢ For more information about model controllers see|Communication considerations using model 
controllers. 


Considerations for the automatic deletion of APPC controller descriptions on the 
LAN 

The system is set to automatically delete APPC controllers and devices that were automatically created. 
The time interval to delete APPC controller is set to 1440 minutes or 24 hours. For virtual APPN 
controllers, the default is 10,000 minutes. The automatic delete controller (AUTODLTCTL) parameter is on 
the CRTLINxxx and CHGLINxxx commands for local area network (LAN) lines. LAN lines include token 
ring, Ethernet, wireless, and distributed data interface (DDI). 


To configure your LAN line to allow automatic deletion of the APPC controller descriptions, use the 

following information: 

* Consider what time of the day would be the best for all users on the system. If automatic deletion 
occurred over the weekend, on Monday morning all devices would be re-created and increase the 
system workload. 
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* Consider when weekends and holidays occur and increase the value of this parameter to take into 
account the most common working environment. 


Note: For personal computers on local area networks, consider using a large value for this parameter 
(for example, 5 days) to prevent deletions if someone goes on vacation. 
¢ The AUTODLTCTL parameter can help manage the number of objects that are on the system. Multiple 
routes through the network can lead to multiple sets of configuration objects. This parameter can be 
used to automate the cleanup of these objects. 


See the following references for more detail: 


¢ For advanced configuration pages, see the |Communications Configuration Ye book. 
¢ For more information about iSeries communications, see the page |Communications Management eS 


book. 


Considerations for controller configuration descriptions that can affect 
error recovery 


The following controller configuration options and device configuration options effect system performance 
during error recovery. 


* AUTODLTDEV(1440), see|“Considerations for automatic delete device (AUTODLTDEV) parameter for 
arnegee| | or *ANS), see|“Considerations for the INLCNN parameter that can affect error recovery” 
lon page 21] page 21 


Switched disconnect, see|“Considerations for the SWTDSC parameter that can affect error recovery” on 
page 21 

APPN minimum switch status, see |“Considerations for the MINSWTSTS parameter that can affect error 
recovery” on page 21 

APPC controller recovery summary, see |“APPC controller recovery summary” on page 22 


Disconnect timer, see|“Considerations for disconnect timer (DSCTMR) parameter for error recovery” on 


page 23 


Additional controller considerations can be found under|“Considerations for the automatic deletion of APPC 


controller descriptions on the LAN” on page 19 


Considerations for automatic delete device (AUTODLTDEV) parameter for error 
recovery 

Device descriptions that are automatically created by the system also may be automatically deleted by the 
system. The default is to delete devices that were automatically created after 1440 minutes (24 hours) if 
they have not been used in that time period. 


Specifying the default has the potential side-effect of having device descriptions deleted over the weekend. 
This can cause a system slow-down. For example, when users reconnect on Monday morning (after a 
48-hour period of system inactivity), they may discover that they need to re-create their device 
descriptions. 


You may want to have the AUTODLTDEV parameter default to a value larger than 24 hours; 72 hours may 
be more appropriate to cover weekends. Use a model controller to change this value for an autocreated 
controller description. 


The default value for devices that are attached to automatically created APPN virtual controllers is 10,000 
minutes. 


Note: Using HPR, or turning on the ALWVRTAPPN network attribute can also solve the problem of having 
multiple sets of configuration objects because HPR prevents multiple objects from being configured. 
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Considerations for the INLCNN parameter that can affect error recovery 

During error recovery, the actions you take to recover the controller depend on whether the controller 
description was created with *DIAL or *ANS specified for the initial connection (INLCNN) parameter. You 
may need to change this parameter for error recovery. The INLCNN parameter is on the CHGCTLxxx 
command or the CRTCTLxxx commands. 


To configure the INLCNN parameter, consider the following: 
¢ Use the INLCNN parameter that is set to *DIAL for iSeries-to-iSeries connections when either system 
may initiate a connection with the other. 


Note: Whether the system actually attempts to DIAL depends on the setting of the Advanced 
Peer-to-Peer Networking (APPN), DIALIMMED, MINSWTSTS, and CTLOWN parameters along 
with the INLCNN parameter. 

¢ Use the INLCNN parameter set to “ANS for iSeries-to-PC connections to avoid unnecessary recovery 
attempts when the personal computer shuts down. 


Note: If the remote system never answers the dial attempt, consider changing the configuration to 
“ANS to avoid dial failures. 


See the following references for more detail: 


¢ For advanced configuration pages, see the |Communications Configuration book. 
it. 
* For more information about iSeries communications, see the}Communications Management|" book. 


Considerations for the SWTDSC parameter that can affect error recovery 

By default, the value for the switched disconnect (SWTDSC) parameter is set to *YES for advanced 
program-to-program communications (APPC). This setting is the best for switched connections. It allows a 
switched line to be disconnected when the application is no longer using the line. You may want to 
consider changing the parameter value for error recovery to eliminate unnecessary disconnections. These 
unnecessary disconnections simply have the iSeries server do more work to disconnect then later 
reconnect. A common environment where this occurs is with personal computers on local area networks 
(LAN) that use the Client Access for Windows or iSeries Access for Windows licensed program. The 
SWTDSC parameter is on the CHGCTLxxx or CRTCTLxxx command. 


To change the SWTDSC parameter, consider the following: 
¢ For personal computers that are connected to a local area network, set the SWTDSC parameter to 
“NO. Connections between personal computers with V installed, and the iSeries server may be 
automatically disconnected if the following conditions exist: 
— The V router is started 
— An application such as a 5250 emulation session or a network drive is not running over the 
connection 
— The application does not start within the time limit that is specified by the disconnect timer 
(DSCTMR) parameter 


Note: If you have a switched line that incurs charges, you should continue to use SWTDSC(*YES). 


See the following references for more detail: 


¢ For advanced configuration pages, see the|Communications Configuration Y book. 
¢ For more information about iSeries communications, see the}Communications Management book. 
Considerations for the MINSWTSTS parameter that can affect error recovery 


The default value for the Advanced Peer-to-Peer Networking (APPN) minimum switched status 
(MINSWTSTS) parameter is set to *VRYONPND. Specifying this parameter makes APPN controllers in 
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vary on pending status available for APPN route selection. You may need to change this parameter value 
for error recovery. The MINSWTSTS parameter is on the CHGCTLAPPC, the CHGCTLHOST, the 
CRTCTLAPPGC, or the CRTCTLHOST commands. 


To change the MINSWTSTS parameter, consider the following: 

¢ Set the MINSWTSTS parameter to *VRYON to limit the routes that APPN recognizes as available. This 
prevents APPN from selecting routes that have a controller in varied on pending status on one system, 
but varied off or inoperative on an adjacent system. 

¢ The switched disconnect (SWTDSC) parameter must be set to *NO when using the MINSWTSTS 
parameter that is set to *VRYON. This makes the connection appear like a leased connection. If you 
have a switched line, do not use MINSWTSTS(*VRTON). 


See the following references for more detail: 


¢ For advanced configuration pages, see the|Communications Configuration cc book. 
¢ For more information about iSeries communications, see the}Communications Management book. 


APPC controller recovery summary 

The action the system takes when advanced program-to-program communications (APPC) controller 
descriptions go into recovery depends on the setting of many parameters. The following tables can help 
you understand and select the appropriate configuration parameters to best optimize system behavior 
when APPC controllers representing personal computer clients go into error recovery. 


Table 1. When does the iSeries attempt to connect the remote system? 


MINSWTSTS INLCNN APPN CTLOWN Power PC Off Manual Vary On 
(recovery) 

*VRYONPND *DIAL *YES *SYS Dial is attempted | Dial is attempted 
*VRYONPND *DIAL *YES *USER Dial not attempted | Dial is attempted 
*VRYONPND *DIAL *NO *SYS Configuration not allowed 

N/A *DIAL *NO *USER Dial not attempted | Dial is attempted 
*VRYONPND *ANS *YES *SYS Dial not attempted | Dial not attempted 
*VRYONPND *ANS *YES *USER Dial not attempted | Dial not attempted 
*VRYONPND *ANS *NO *SYS Configuration not allowed 

N/A *ANS *NO *USER Dial not attempted | Dial not attempted 


Table 2. MINSWTSTS(*VRYON) affects on iSeries attempts to connect to the remote system 


APPN INLCNN CTLOWN SWTDSC Power PC Off Manual Vary On 
(recovery) 

*YES *DIAL *SYS *YES Configuration not allowed 

*YES *DIAL *SYS *NO Dial is attempted | Dial is attempted 

*YES *DIAL *USER *YES Configuration not allowed 

*YES *DIAL *USER *NO Dial is attempted | Dial is attempted 


Note: In all cases when a dial is attempted, when the remote system is using a PC with Client Access for 
Windows or iSeries Access for Windows installed, that dial attempt fails with the following message: 


CPA57EF to QSYSOPR (Controller contact not successful) 


For related information, see: 


“Considerations for controller configuration descriptions that can affect error recovery” on page 20 
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Considerations for disconnect timer (DSCTMR) parameter for error recovery 

The disconnect timer (DSCTMR) parameter controls the time before a connection without activity is 
dropped, or the amount of time to delay the automatic disconnection. The default value is 170 seconds. 
The range is 0 - 65536 seconds. 


The DSCTMR parameter is on the CHGCTLxxx and CRTCTLxxx commands. 


For related information, see: 


* |“Considerations for controller configuration descriptions that can affect error recovery” on page 20 


Considerations for modes that can affect error recovery 


A mode description is a system object that is created for communications devices to describe the 
session limits and the characteristics of the session. These characteristics can be any of the following: 
* The maximum number of sessions allowed 

* The maximum number of conversations allowed 

* The pacing value for incoming request 

* The maximum size of request units 

¢ Other controlling information for the session 


You can view, create, change, and work with mode descriptions using the Work with Mode Descriptions 
(WRKMODD) command. 


The QPCSUPP (PC support) mode and QSERVER (server) modes are used by the Client Access for 
Windows or iSeries Access for Windows licensed program. 


Considerations for jobs that can affect error recovery 


When a line or controller fails, and the application programs are notified, often you must end those jobs 
that were running over the line and controller. Those jobs must be started again after the communications 
resource is recovered. Jobs ending (particularly abnormal job ending) should be considered from a 
performance perspective as an extremely complex transaction. Use the following links to help you recover 
from an abnormal job ending. 


* Device recovery, see|“Considerations for the CMNRCYLMT parameter that can affect error recovery” 


¢ Prestart jobs, see /‘Change prestart job entries that can affect APPC error recovery” on page 2 


¢ Joblog generation, see|“Joblog considerations that can affect communications error recovery” on 
page 26 25 


¢ Using the Change System Job (CHGSYSJOB) commands 


The CHGSYSJOB command allows you to change the run priority of a system job. The following are 
system jobs of interest for communications recovery: 

— QCMNARB01 through QCMNARB99 

—- QSYSCOMM1 


iS 


In general, these system jobs should be allowed to run at their default, system-provided priority. 
However, if one of these jobs begins using large amounts of CPU, and is affecting other work on the 
system, it is possible to lower its priority. Note that this may result in queued-up work for that job. 

* Device Wait Timeout 


The device wait (DEVWAIT) timeout is used to limit the amount of time a subsystem waits for 
workstation input/output to complete. 


Considerations for the CMNRCYLMT parameter that can affect error recovery 
The QCMNRCYLMT system value or the recovery limits (CMNRCYLMT) parameter on the configuration 
object controls automatic communications error recovery. The CMNRCYLMT parameter is on the 
CHGCTLxxx, CHGLINxxx, CHGNWIxxx, CRTCTLxxx, CRTLINxxx, or CRTNWIxxx commands. These 
parameter values contain two related numbers that you can set: 

* The number of second-level recovery attempts automatically performed by the system (count limit) 

* The length of time (time interval) in which the specified number of second-level recoveries can occur. 
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The default value on CMNRCYLMT on lines and controllers is two retries within 5 minutes (2 5). 


To configure the CMNRCYLMT parameter, consider the following: 
* If automatic communication fails for personal computers on a local area network (LAN); and the iSeries 
attempts to recover the connection, this places unnecessary work on the system. 


Note: If automatic communications error recovery is not used, manual recovery is necessary, that 
requires operator intervention. A good compromise is to set the automatic recovery limits to just 
one retry. 

¢ Use acount limit 0 and a time interval of more than 0 to turn off second-level error recovery. Turning off 
second-level recovery may cause the devices and controllers to go into recovery pending (RCYPND) 
state. A message is sent to QSYSOPR, or the configured message queue, that requires operator 
intervention. Use manual recovery to either respond to the message in QSYSOPR, or the configured 
message queue, or vary the objects off and back on. 


Note: First-level error recovery is still done. On a LAN, the Inactivity Timer is used to determine if the 
remote system is still available. Once the inactivity time expires, first-level error recovery is driven 
by the LANFRMRTY parameter and the LANRSPTMR parameter. 

¢ Write applications that can determine if a failure has occurred, and then handle the errors. 

— Monitor the error messages in QSYSOPR, or the configured message queue, when they occur and 

handle the condition. 

— Monitor the status of the configuration objects by using Retrieve Configuration Status (QODCRCFGS) 

and List Configuration Descriptions (QODCLCFGD) application program interfaces (API). 


See the following references for more detail: 


¢ For advanced configuration pages, see the|\Communications Configuration|book. Ye 
¢ For more information about iSeries communications, see the}Communications Management book. 


For related information, see: 

Change prestart job entries that can affect APPC error recovery 

Using prestart jobs greatly reduces startup time of the connection. Jobs are reused rather than ended. 
After an error, users are able to reconnect more quickly. Prestart job entries are shipped with the system 
for QCMN, QBASE, and QSERVER for these server jobs. You may want to change the prestart job 


entries. The prestart job entries depend on the usage of your system and the servers during error recovery 
situations. 


Change the prestart jobs entries as appropriate for your environment. 
* Consider the following parameters and their values: 
— STRJOBS(*YES and *NO) 
INLJOBS 
— THRESHOLD 
ADLJOBS 
— MAXJOBS 
¢ Use the INLJOB parameter to make a larger number of jobs available for the following reasons: 
— You have many users who will connect to the system. 
— The connect processing is to be done as quickly as possible. 
* Make sure that the THRESHOLD value is higher than the total number of active users. 
* Make sure that the ADLJOBS value is higher than the number of jobs that is used. 


Note: As user applications are developed, consider using prestart jobs to reduce program start request 
startup processing. 
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Tip: Change prestart job entries for APPC error recovery: To display the inactive prestart jobs, press 
F14 on the WRKACTJOB display. This display can be used to include jobs that are typically not shown on 
the WRKACTJOB displays. Inactive prestart jobs show a status of PSRW (program start request wait). 


See the following references for more detail: 


¢ For advanced configuration pages, see the|\Communications Configuration e book. 
a. 


¢ For more information about iSeries communications, see the}Communications Management|" book. 


¢ For more server considerations, see |iSeries Access Express 


For related information, see: 


* |“Joblog considerations that can affect communications error recovery” 
* |“Work entries” 


Joblog considerations that can affect communications error recovery 

You should consider whether to generate job logs when an error condition occurs and the active jobs are 
ended. Producing job logs can use considerable system resources, especially during error recovery in 
which many jobs end at one time. In this case, it may be better to not generate job logs. If you do not 
produce job logs, you will not have any data for analysis if something goes wrong. There is a trade-off to 
be made. 


To configure your system so that job logs are not generated, do the following: 
* Set the DEVRCYACN parameter to *ENDJOBNOLIST. There is also a Q(DEVRCYACN system value for 
ease of configuration. 


Note: The QDSCJOBITV system value determines when the unused disconnected jobs are ended. 

¢ Change the job description (or the job itself through an initial program for the user profile) to LOGLVL(4 
0 *NOLIST). With this description, the job logs are not generated if jobs end normally, but are generated 
if jobs end abnormally. 


Note: Disconnected jobs also use resources. The System Work Control Block Table can grow, which 
has other side effects. Do not disconnect from jobs to which you will never reconnect. 


If some of your users reconnect after a failure, however, the disconnect options can offer 
increased performance for them. 


¢ For advanced configuration pages, see the |Communications Configuration Y book. 
* For more information about iSeries communications, see the}Communications Management book. 
¢ For system management pages, see the|Work Management e book. 


For related information, see: 
* |“Considerations for jobs that can affect error recovery” on page 23 
¢ |“Considerations for communications-related system values” on page 17 


Work entries: |n a subsystem description, work entries are defined to identify the sources from which 
jobs can be started in that subsystem. The types of work entries are as follows: 
Autostart job entry 
Specifies a job that is automatically started when the subsystem is started. 
Workstation entry 
Specifies one or a group of workstations from which interactive jobs can be started. 
Job queue entry 
Specifies one of the job queues from which the subsystem can select batch jobs. A batch job is a 
job that can run independently of a user at a workstation. 
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Communications entry 
Specifies one or a group of communications device descriptions from which communications batch 
jobs may be started. Communications batch jobs do not use job queues. 

Prestart job entry 
Identifies an application program to be started to wait for incoming allocation requests. 


Connect a PC to iSeries 400 using Personal Communications 


To obtain greater benefits from having an iSeries in the workplace, personal computers should be able to 
connect with the iSeries. This means you can have an iSeries terminal anywhere there is a personal 
computer. Personal Communications Version 2.1 is one way to connect a PC to an iSeries. To connect a 
PC to an iSeries with Personal Communications, the PC must have Windows 95/NT installed. 


To configure the Personal Communications Version 2.1 for Windows 95 session to use SNA 
communications over a local area network (LAN), do the following: 
1. From the START menu, choose Programs - IBM Personal Communication - Start/Configure Session. 
The Customize Communication window appears. 
2. Highlight the following: 
¢ LAN for interface 
¢ IEEE 802.2 for attachment 
* iSeries for host 
3. Click Configure. The Customize Communication-5250 Host window appears. 
4. Type in the session parameters (screen size, session type, host graphics, and so on) or use the 
default parameters. 
¢ For System Location name, give it the iSeries Local Network ID name and Local Control Point 
name. (You can find these names with the Display Network Attributes (DSPNETA) command on the 
iSeries you want to connect to.) 
* Fill in the PC Location name as appropriate for your PC. For the Workstation ID, use a name. A 
common choice is to use the location name that is added to the end. 
5. To configure the link parameters, click Configure Link. 
¢ Fill in the adapter address with the LAN adapter address of your iSeries. Typically, SAP and PIU 
sizes can be set by the default. 
6. Click OK and the Customize Communication window disappears. 
7. Click Communication to make the connection to your iSeries. 


Configure APPC with VTAM 


You need to coordinate the following Virtual Telecommunications Access Method (VTAM) and advanced 

program-to-program communication (APPC) configuration objects when configuring APPC with VTAM. 

1. The controller description is equivalent to the IBM Network Control Program and Virtual 
Telecommunications Access Method (NCP/VTAM) PU macros. You can find the information in a 
controller description in the Extended Services Communication Manager Partner LU profile. 

2. The device description is equivalent to the NCP/VTAM logical unit (LU) macro. You can find the 
information of a device description in Extended Services Communications Manager Partner LU and LU 
profiles. 

3. The mode description is equivalent to the NCP/VTAM mode tables. You can find the information in a 
mode description in the Extended Services Communications Manager Transmission Service Mode 
profile and Initial Session Limits profile. 
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Chapter 4. APPC, APPN, and HPR configuration examples 
If you are configuring using APPN, you may want to see[APPN configuration examples| 


HPR is the evolution of Advanced Peer-to-Peer Networking (APPN). HPR enhances APPN data routing 
performance and reliability, especially when using higher-speed, lower error links. To see an example of 
configuring HPR, see the page}HPR configuration examples 

This |disclaimer information|pertains to code examples. 


APPN configuration examples 


See the following examples for a variety of ways to configure APPN: 


Notes: 

1. In all of the examples, default values are used for all parameters not explicitly defined. 

2. The name assigned to each description that is created is the same as the name of the destination that 
is being defined in that description. For example, the line description configured in New York for the 
connection to Los Angeles is LOSANGEL. 

3. Names (such as location names), telephone numbers, exchange identifiers, and other values that 
shown in the examples are for illustration only. The values you assign to your configuration are 
dependent on your network requirements. 


Note: Read the|code disclaimer information| for important legal information. 


Two iSeries systems as end nodes using APPN 


In Figure 4, systems A and B are both configured as end nodes in the network attributes. The only 
APPN-specific parameter that must be configured is the remote control-point name in the controller 
description. A device description is not a requirement for an APPN configuration. 


End Hode End Hode 
Hew York Los Angeles 
RSLShia 


Figure 4. Two-system APPN network 


Each list below represents a city within the network in Figure 4 above. See the links in each list to 
determine the configuration requirements for each system. 


New York 

* |“Example: Configure system A (New York) as an end node” on page 28 

* |“Change the network attributes (New York) in two-system network” on page 28 
* |“Create the line description (New York) in two-system network” on page 29 
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* |“Create the controller description (New York) in two-system network” on page 29 


Los Angeles 

“Configure system B (Los Angeles) as end node” on page 29 
“Change the network attributes (Los Angeles) in two-system network” on page 30 
“Create the line description (Los Angeles) in two-system network” on page 30 
“Create the controller description (Los Angeles) in two-system network” on page 30 


Example: Configure system A (New York) as an end node 

The following CL commands are used to define the configuration for the system that is NEWYORK. The 
example shows the commands as used within a CL program; the configuration can also be performed 
using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[RRR RK KKK KEI AKA K KKK KKK KKK KKK KAKI KKK KKK KKK KAKA KK EA KEK A KER | 


/* x/ 
/* MODULE: NYLAAPPN LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL x/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN ENDNODES AS FOLLOWS: x/ 
/* x/ 
/* NEWYORK = / \ LOSANGEL x/ 
/* \ / x/ 
/* x/ 
/* (THIS IS NEWYORK TO LOSANGEL) x/ 
TTT TTT ETT TT ETT ETT LTTE EEE LEE E EEE EE ERTL TELLER EEEEEEEELEL 
PGM 

STITT T ETT LETTE TEE E TALE LEE EEE EEE RE REECE EEE EERE EEE 
/* NEWYORK TO LOSANGEL */ 


[BRK RK KEK KK EAR K EA KKK KKK KKK KKK KEK IKARIA KEK KKK AIK IKK EK AREA KER | 


/* Change network attributes for NEWYORK ~*/ 

CHGNETA LCLNETID(APPN) LCLCPNAME (NEWYORK) 
LCLLOCNAME (NEWYORK) NODETYPE(*ENDNODE) 

/* Create line description for NEWYORK to LOSANGEL */ 

CRTLINSDLC LIND(LOSANGEL) RSRCNAME(LINO11) 

/* Create controller description for NEWYORK to 

LOSANGEL */ 

CRTCTLAPPC CTLD(LOSANGEL) LINKTYPE(*SDLC) LINE(LOSANGEL) 
RMTNETID(APPN) RMTCPNAME(LOSANGEL) 
STNADR(@1) NODETYPE(*CALC) 

ENDPGM 


Change the network attributes (New York) in two-system network 
Use the Change Network Attributes (CHGNETA) command to set the attributes for the system within the 
network. The following attributes are for NEWYORK: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote location (LOSANGEL) must specify 
this name as the remote network identifier (RMTNETID) on the CRTCTLAPPC command. 


LCLCPNAME(NEWYORK) 
Specifies that the name assigned to the local control point is NEWYORK. The remote system specifies 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(NEWYORK) 
The default local location name is NEWYORK. This name will be for the device description that is 
created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (NEWYORK) is an APPN end node. 
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Create the line description (New York) in two-system network 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
Create Line Description (SDLC) (CRTLINSDLC). The parameters specified are: 


LIND(LOSANGEL) 
The name assigned to the line description is LOSANGEL. 


RSRCNAME(LINO11) 
Specifies that the physical communications port named LINO11. 


Create the controller description (New York) in two-system network 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(LOSANGEL) 
The name assigned to the controller description is LOSANGEL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line in use defined by a create line description 
command. 


LINE(LOSANGEL) 
Specifies the name (LOSANGEL) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(LOSANGEL) 
Specifies that the remote control-point name is LOSANGEL. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the 
LCLCPNAME parameter of the CHGNETA command specifies the name at the remote system 
(LOSANGEL) by: 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*CALC) 
Specifies that the local system must determine, during exchange identifier processing, the node type 
of the remote system. 


Configure system B (Los Angeles) as end node 

The following CL commands define the configuration for the system that is identified as LOSANGEL 
(System B). The example shows the commands as used within a CL program; the configuration can also 
be performed using the configuration menus. 


Note: Read the|code disclaimer information|for important legal information. 


[BRK K RRA KK EAR KER KKK EKER KEK AK KEK KK IK KIA KEKE KAKA KEE AKER KRERKKE | 


/* */ 
/* MODULE: LANYAPPN LIBRARY: PUBSCFGS x/ 
/* */ 
/* LANGUAGE: CL x/ 
/* */ 
/* FUNCTION: CONFIGURES APPN ENDNODES AS FOLLOWS: */ 
//* */ 
/* NEWYORK / \ LOSANGEL x/ 
/* \ / */ 
/* */ 
/* (THIS IS LOSANGEL TO NEWYORK) x/ 
/* */ 


[BRK K KKK KEIR KAKA KKK IKK KK KK KK IK KIA KKK KK KEI KIKI KER AK KEK AKER KK | 
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PGM 


[BRK RK ERA KKE IKKE IKKE KKK KKK AK KEK KKK KKK AKER IKEA IKEA KK EKER AKER KK | 


/* LOSANGEL TO NEWYORK x/ 
[BRK R KEK K KEIR KEIR K KKK EIR K KKK KEK KKK KKK AKAIKE AK KEK AKER A KER | 
/* Change network attributes for LOSANGEL ~*/ 

CHGNETA LCLNETID(APPN) LCLCPNAME (LOSANGEL) 

LCLLOCNAME(LOSANGEL) NODETYPE(*ENDNODE) 
/* Create line description for LOSANGEL to NEWYORK «/ 
CRTLINSDLC LIND(NEWYORK) RSRCNAME(LINO12) 
/* Create controller description for LOSANGEL to 
NEWYORK */ 
CRTCTLAPPC CTLD(NEWYORK) LINKTYPE(*SDLC) LINE (NEWYORK) 
RMTNETID(APPN) RMTCPNAME (NEWYORK) 
STNADR(Q1) NODETYPE(*CALC) 
ENDPGM 


Change the network attributes (Los Angeles) in two-system network 
Use the Change Network Attributes (CHGNETA) command to set the attributes for the system within the 
network. The following attributes are for LOSANGEL: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote location (NEWYORK in the 
example) must specify this name as the remote network identifier (RMTNETID) on the CRTCTLAPPC 
command. 


LCLCPNAME(LOSANGEL) 
Specifies that the name assigned to the local control point is LOSANGEL. The remote system 
specifies this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC 
command. 


LCLLOCNAME(LOSANGEL) 
The default local location name is LOSANGEL. This name is for the device description that is created 
by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (LOSANGEL) is an APPN end node. 


Create the line description (Los Angeles) in two-system network 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(NEWYORK) 
The name assigned to the line description is NEWYORK. 


RSRCNAME(LINO12) 
Specifies that the physical communications port named LINO12. 


Create the controller description (Los Angeles) in two-system network 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(NEWYORK) 
The name assigned to the controller description is NEWYORK. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line in use as defined by a create line description 
command. 


LINE(NEWYORK) 
Specifies the name (NEWYORK) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 
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RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(NEWYORK) 
Specifies that the remote control-point name is NEWYORK. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the 
LCLCPNAME parameter of the CHGNETA command specifies the name at the remote system 
(NEWYORK). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*CALC) 
Specifies that the local system must determine, during exchange identifier processing, the node type 
of the remote system. 


Two iSeries systems as network nodes using APPN 


In Figure 5, both systems are configured as network nodes in the network attributes. This example shows 
an APPN configuration using a switched line and a nonswitched line. 


Configuring Network Node 1 (Chicago) 
The following example program shows the CL commands that are used to define the configuration for the 


system that is identified as CHICAGO (NN1). The example shows the commands as used within a CL 
program; the configuration can also be performed using the configuration menus. 


Hetwork Hode Hetwork Hode 


Honekwitched Line 


Switched Line 2 - 
Chicago Minneapolis 


RSLSSé4-0 


Figure 5. APPN two-system network 


Each list below represents a city within the network in Figure 5 above. See the links in each list to 
determine the configuration requirements for each system. 


Chicago 

* |“Change the network attributes (Chicago) in two-system network” on page 32 

* |“Create the line description (Chicago to Minneapolis, nonswitched)” on page 33 

¢ |“Create the controller description (Chicago to Minneapolis, nonswitched)” on page 33 
¢ |“Create the line description (Chicago to Minneapolis, switched)” on page 33 

* |“Create the controller description (Chicago to Minneapolis, switched)” on page 34 


Minneapolis 
* |“Configure network node 2 (Minneapolis) on page 34| 
* |“Change the network attributes (Minneapolis) as a network node” on page 35 


¢ |“Create the line description (Minneapolis to Chicago, nonswitched)” on page 35 


¢ |“Create controller description A (Minneapolis to Chicago)” on page 35 
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* |“Create the line description (Minneapolis to Chicago, switched)” on page 36 
* |“Create controller description B (Minneapolis to Chicago)” on page 36 


Change the network attributes (Chicago) in two-system network 

Use the Change Network Attributes (CHGNETA) command to set the attributes for the system within the 
network. The following attributes are defined for the CHICAGO system, and these attributes apply to all 
connections in the network for this network node. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK R KERR KER KK AK KEIRA KKK KKK ERK KERIKERI KEKE KARE EKER | 


/* */ 
/* MODULE: CHICAGO LIBRARY: PUBSCFGS */ 
/* */ 
/* LANGUAGE: CL */ 
/* */ 
/* FUNCTION: CONFIGURES APPN NETWORK: */ 
/* */ 
/* THIS IS: CHICAGO TO MPLS (nonswitched) */ 
/* CHICAGO TO MPLS (switched) */ 
/* */ 
/* */ 
/* */ 
/* */ 
[BERR KERR KEKE AK ERIK KEIRA KEK KKK KKK KKK AKER KKK KAKA KEK AKER EKER | 
PGM 


/* Change network attributes for CHICAGO */ 
CHGNETA LCLNETID(APPN) LCLCPNAME(CHICAGO) + 
LCLLOCNAME (CHICAGO) NODETYPE(*NETNODE) 
[BRK RRR KKK EAR KR AK KEIRA KEIR KEK KKK AKER AKER IKEA KKK KK EKA KER AKER | 
/* CHICAGO TO MPLS (nonswitched) */ 
[KEK KKK KKK KKK A KKK AK KA KKK KKK IK KKK KKK KKK AK KKK KKK KK EA KEE RAKE | 
/* Create nonswitched line description for CHICAGO to MPLS «/ 
CRTLINSDLC LIND(MPLSL) RSRCNAME(LINO21) 
/* Create controller description for CHICAGO to MPLS «/ 
CRTCTLAPPC CTLD(MPLSL) LINKTYPE(*SDLC) LINE(MPLSL) + 
RMTNETID(APPN) RMTCPNAME(MPLS) + 
STNADR(01) NODETYPE(*NETNODE) 
[RE K RRR AKER IKKE AK KR AK KKK KEIRA KKK AKER AKER IKEA KEI AKER AKER AKER | 
/* CHICAGO TO MPLS (switched) */ 
[BRK R KEK K KEIR K RAK KEIRA KKK KK EAR K KKK AKER IKEA KKK AREA AKER EKER | 
/* Create switched line description for CHICAGO to MPLS */ 
CRTLINSDLC LIND(MPLSS) RSRCNAME(LINO22) CNN(*SWTPP) + 
AUTOANS(*NO) STNADR(01) 
/* Create controller description for CHICAGO to MPLS «/ 
CRTCTLAPPC CTLD(MPLSS) LINKTYPE(*SDLC) SWITCHED(*YES) + 
SWTLINLST(MPLSS) RMTNETID(APPN) + 
RMTCPNAME(MPLS) INLCNN(*DIAL) + 
CNNNBR(6125551111) STNADR(01) + 
TMSGRPNBR(3) NODETYPE(*NETNODE) 
ENDPGM 


LCLNETID(APPN) 
The name of the local network is APPN. The remote system (MPLS in the example program, NN2 in 
must specify this name as the remote network identifier (RMTNETID) on the 
CRICTLAPPC command. 


LCLCPNAME(CHICAGO) 
The name assigned to the local control point is CHICAGO. The remote systems specify this name as 
the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(CHICAGO) 
The default local location name is CHICAGO. This name will be used for the device description that is 
created by the APPN support. 
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NODETYPE(*NETNODE) 
The local system (CHICAGO) is an APPN network node. 


Create the line description (Chicago to Minneapolis, nonswitched) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLSL) 
The name assigned to the line description is MPLSL. 


RSRCNAME(LINO21) 
The physical communications port named LINO21. 


Create the controller description (Chicago to Minneapolis, nonswitched) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(MPLSL) 
The name assigned to the controller description is MPLSL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


LINE(MPLSL) 
The name of the line description to which this controller is attached is MPLSL. This value must match 
a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
The remote control-point name is MPLS. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the LCLCPNAME 
parameter on the Change Network Attributes (CHGNETA) command specifies the name at the remote 
system (NEWYORK). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
The remote system (MPLS) is an APPN network node. 


Create the line description (Chicago to Minneapolis, switched) 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLSS) 
The name assigned to the line description is MPLSS. 


RSRCNAME(LINO22) 
The physical communications port that is named LINO22. 


CNN(*SWTPP) 
This is a switched line connection. 


AUTOANS(*NO) 
This system will not automatically answer an incoming call. 


STNADR(01) 
The address assigned to the local system is hex 01. 


Chapter 4. APPC, APPN, and HPR configuration examples 33 


Create the controller description (Chicago to Minneapolis, switched) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(MPLSS) 
The name assigned to the controller description is MPLSS. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


SWITCHED(*YES) 
This controller attaches to a switched SDLC line. 


SWTLINLST(MPLSS) 
The name of the line description (for switched lines) to which this controller can be attached is 
MPLSS. In the example, there is only one line (MPLSS). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
The remote control-point name is MPLS. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the LCLCPNAME 
parameter on the CHGNETA (Change Network Attributes) command specifies the name at the remote 
system. 


INLCNN(*DIAL) 
The iSeries system makes the initial connection by either answering an incoming call or placing a call. 


CNNNBR(6125551111) 
The connection (telephone) number for the remote controller is 6125551111. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


TMSGRPNBR(3) 
APPN support use the value (3) for transmission group negotiation with the remote system. 


The remote system must specify the same value for the transmission group. 
NODETYPE(*NETNODE) 
The remote system (MPLS) is an APPN network node. 


Configure network node 2 (Minneapolis) 

The following example program shows the CL commands that are used to define the configuration for the 
system that is identified as MPLS (NN2 in [Figure 5 on page 31). The example shows these commands as 
used within a CL program; the configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[RE KR KEK KK EAR KEK KKK KEK KKK KEKE IKK AAR E KKK KIA KEE IKKE KKK A KER | 


/* */ 
/* MODULE: MPLS LIBRARY: PUBSCFGS */ 
/* */ 
/* LANGUAGE: CL */ 
/* */ 
/* FUNCTION: CONFIGURES APPN NETWORK: */ 
/* */ 
/* THIS IS: MPLS TO CHICAGO (nonswitched) */ 
/* MPLS TO CHICAGO (switched) */ 
/* */ 
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/* */ 
[BRK RK KEK K REAR K ER KKK KKK KKK AK KEK KK AKKIAKKEKKKEK AIK A KIKI KK EA AREA | 
PGM 
/* Change network attributes for MPLS */ 
CHGNETA LCLNETID(APPN) LCLCPNAME(MPLS) + 
LCLLOCNAME (MPLS) NODETYPE(*NETNODE) 


[BRK K RRA KK EAR KEIRA KKK IKKE KA KKK KK AK KIKI KKK A KIKI KK AKEE AAR | 


/* MPLS TO CHICAGO (nonswitched) */ 


[RRR RK KARR RAK KEK AKA KKK IKKE KKK IK KKK KKK KKK AKIRA KER A KK E KARE | 
/* Create line description for MPLS to CHICAGO */ 
CRTLINSDLC LIND(CHICAGOL) RSRCNAME(LINO22) 
/* Create controller description for MPLS to CHICAGO «/ 
CRTCTLAPPC CTLD(CHICAGOL) LINKTYPE(*SDLC) LINE(CHICAGOL) + 
RMTNETID(APPN) RMTCPNAME(CHICAGO) + 
STNADR(01) NODETYPE (*NETNODE) 


[BRK RK RRA K REAR KER KKK AK KEK KEK AKER KKK KK A KKK AKA KIKI KEE AKER AAR | 


/* MPLS TO CHICAGO (switched) */ 
[ REKRK ERK KK EAK KEIR KEK AKER KEK AK KEA KKK KK AKKEKK KE A AIK A KER AKKE AIRE | 
/* Create switched line description for MPLS to CHICAGO */ 
CRTLINSDLC LIND(CHICAGOS) RSRCNAME(LINO31) CNN(*SWTPP) + 
AUTOANS(*NO) STNADR(01) 
/* Create controller description for MPLS TO CHICAGO «/ 
CRTCTLAPPC CTLD(CHICAGOS) LINKTYPE(*SDLC) SWITCHED(*YES) + 
SWTLINLST(CHICAGOS) RMTNETID(APPN) + 
RMTCPNAME (CHICAGO) INLCNN(*ANS) + 
CNNNBR(3125551111) STNADR(01) TMSGRPNBR(3) + 
NODETYPE (*NETNODE) 
ENDPGM 


Change the network attributes (Minneapolis) as a network node 

The Change Network Attributes (CHGNETA) command sets the attributes for the system within the 
network. The following attributes are defined for the MPLS system, and these attributes apply to all 
connections in the network for this network node: 


LCLNETID(APPN) 
The name of the local network is APPN. The remote systems (CHICAGO in the example program, 
NN1 in [Figure 5 on page 31) must specify this name as the remote network identifier (RMTNETID) on 
the CRTCTLAPPC command. 


LCLCPNAME(MPLS) 
The name assigned to the local control point is MPLS. The remote system specifies this name as the 
remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(MPLS) 
The default local location name is MPLS. This name is for the device description that is created by the 
APPN support. 


NODETYPE(*NETNODE) 
The local system (MPLS) is an APPN network node. 


Create the line description (Minneapolis to Chicago, nonswitched) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGOL) 
The name assigned to the line description is CHICAGOL. 


RSRCNAME(LINO22) 
The physical communications port named LINO22. 


Create controller description A (Minneapolis to Chicago) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 
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CTLD(CHICAGOL) 
The name assigned to the controller description is CHICAGOL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


LINE(CHICAGOL) 
The name of the line description to which this controller is attached is CHICAGOL. This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote system resides is APPN. 


RMTCPNAME(CHICAGO) 
The remote control-point name is CHICAGO. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the LCLCPNAME 
parameter on the Change Network Attributes (CHGNETA) command specifies the name at the remote 
system (CHICAGO). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
The remote system (CHICAGO) is an APPN network node. 


Create the line description (Minneapolis to Chicago, switched) 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGOS) 
The name assigned to the line description is CHICAGOS. 


RSRCNAME(LINO31) 
The physical communications port named LINO31. 


CNN(*SWTPP) 

This is a switched line connection. 
AUTOANS(*NO) 

This system will not automatically answer an incoming call. 
STNADR(01) 


The address assigned to the local system is hex 01. 


Create controller description B (Minneapolis to Chicago) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(CHICAGOS) 
The name assigned to the controller description is CHICAGOS. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


SWITCHED(*YES) 
This controller is attached to a switched SDLC line. 


SWTLINLST(CHICAGOS) 
The name of the line description (for switched lines) to which this controller can be attached is 


36 iSeries: Networking APPC, APPN, and HPR 


CHICAGOS. In the example, there is only one line (CHICAGO). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
The remote control-point name is CHICAGO. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the LCLCPNAME 
parameter on the Change Network Attributes (CHGNETA) command specifies the name at the remote 
system (CHICAGO). 


INLCNN(*ANS) 
The iSeries system makes the initial connection by answering an incoming call. 


CNNNBR(3125551111) 
The connection (telephone) number for the remote controller is 3125551111. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


TMSGRPNBR(3) 
APPN support uses the value (3) for transmission group negotiation with the remote system. 


The remote system must specify the same value for the transmission group. 


NODETYPE(*NETNODE) 
The remote system (CHICAGO) is an APPN network node. 


Three iSeries systems using APPN 


In Figure 6, A and B are end nodes. The network node must configure its network attributes to reflect that 
it is a network node. Each system must configure the remote control-point name in the controller 
description that represents the adjacent system. Also, A and B must indicate in the controller description 
for the network node that it can be a network node. A and B must add the network node to the server list 
in network attributes so that the network node could act as a network server for both end nodes. 


Note: Neither end node needs to configure any information about the other end node. 


EndHode WNetyvork Node End Hode 


G 


Hew York Ghicago Los Angeles 
RSLSHS3 


Figure 6. Three-system APPN network 


Each list below represents a city within the network in Figure 6 above. See the links in each list to 
determine the configuration requirements for each system. 


New York 

* |“Configure system A (New York)” on page 38 

* |“Change the network attributes (New York) in three-system network” on page 39 

* |“Create the remote location configuration list (New York) in three-system network” on page 39 
* |“Create the line description (SDLC nonswitched - New York)” on page 39 
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¢ |“Create the controller description in three-system network (New York)” on page 40 


Los Angeles 

“Configure system B (Los Angeles)” on page 40 
“Change the network attributes (Los Angeles) in three-system network” on page 41 
“Create the remote location configuration list (Los Angeles)” on page 41 
“Create the line description (Los Angeles)” on page 41 
“Create the controller description (Los Angeles)” on page 42 


“Configure system C (Chicago)” on page 42 
“Change the network attributes (Chicago) in three-system network” on page 43 
“Create the line description (Chicago to New York) in three-system network” on page 4 
“Create the controller description (Chicago to New York) in three-system network” on page 43 
“Create the line description (Chicago to Los Angeles)” on page 4 
* |“Create the controller description (Chicago to Los Angeles)” on page 44 


® 


Configure system A (New York) 
The following CL commands defines the configuration for the system that is identified as NEWYORK 
(system A in|Figure 6 on page 37). The examples show these commands as used within a CL program; 


the configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[RE KR KEK K KEIR K EA KKK EKER KKK KEK KEI KKKAKEKKKEIA IKEA KKK AREA KEKE | 


|x */ 
/* MODULE: NYCHENNN LIBRARY: PUBSCFGS */ 
|x */ 
/* LANGUAGE: CL */ 
|x */ 
/* FUNCTION: CONFIGURES APPN EN-NN-EN AS FOLLOWS: */ 
|x */ 
x */ 
/* NEWYORK / \ CHICAGO / \ LOSANGEL */ 
x \ / \ / */ 
|x */ 
/* (THIS IS NEWYORK TO CHICAGO) */ 
|x */ 
|x */ 
[x */ 
[ REKRK KKK KER KKK IKKE KKK KKK KKK KKK KKK KKK AKA KKK AIK AK KEK AKER AKER KK | 
PGM 

[BRK R KEK KEIRA KK ERK K KIKI KKK KK EAR KEKKKEKAKEK KKK I AIK E AK KEK EKER AKER | 
/* NEWYORK TO CHICAGO */ 


[KEK RK KK KK ERK KAA KER KKK KKK KKK KKK IK KKK KEK KK KIARA KEK AKER AKER KK | 
/* Change network attributes for NEWYORK ~*/ 
CHGNETA LCLNETID(APPN) LCLCPNAME (NEWYORK) 
LCLLOCNAME (NEWYORK) NODETYPE(*ENDNODE) 
NETSERVER((APPN CHICAGO) ) 
/* Create remote configuration list for NEWYORK */ 
CRTCFGL TYPE(*APPNRMT) APPNRMTE((LOSANGEL APPN 
NEWYORK LOSANGEL APPN 3BD29F *YES *NO «NO *NO 
'RMT LOC of NEWYORK')) 
/* Create line description for NEWYORK to CHICAGO «/ 
CRTLINSDLC LIND(CHICAGO) RSRCNAME(LINO11) 
/* Create controller description for NEWYORK to 
CHICAGO */ 
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CRTCTLAPPC CTLD(CHICAGO) LINKTYPE(*SDLC) LINE(CHICAGO) 
RMTNETID(APPN) RMTCPNAME (CHICAGO) 
STNADR(Q1) NODETYPE(*NETNODE) 
ENDPGM 


Change the network attributes (New York) in three-system network 
The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes for NEWYORK: 


LCLNETID(APPN) 
Specifies that_the name of the local network is APPN. The remote location (CHICAGO in the example, 
system B in [Figure 6 on page 37}, must specify this name as the remote network identifier 
(RMTNETID) on the CRTCTLAPPC command. 


LCLCPNAME(NEWYORK) 
Specifies that the name assigned to the local control point is NEWYORK. The remote system specifies 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(NEWYORK) 
The default local location name of this location is NEWYORK. This name will be used for the device 
description that is created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (NEWYORK) is an end node in the APPN network. 


NETSERVER((APPN CHICAGO)) 
Specifies the name of the network node (CHICAGO) and the name of the network (APPN) that serves 
this end node. These names are defined at the remote system on the CHGNETA command. 


Create the remote location configuration list (New York) in three-system network 
The Create Configuration List (CRTCFGL) command is also used to define the remote locations with 
special characteristics to the APPN support. In this example, location security is being used, and the 
following is defined at NEWYORK: 


TYPE(*APPNRMT) 
Specifies that the entries being defined are remote locations. 


APPNRMTE((LOSANGEL APPN NEWYORK LOSANGEL APPN 3BD29F *YES *NO *NO *NO ’RMT 
LOC of NEWYORK’)) 
Specifies the remote location with which the local location can be paired. 


¢ The remote location name is LOSANGEL 

* The remote network ID is APPN 

* The associated local location name is NEWYORK 
* The remote control-point name is LOSANGEL 

* The remote control-point network ID is also APPN 
* The password is 3BD29F 

* It is a secure location 


* It is not a single session location (the last two entries, locally controlled sessions and 
pre-established sessions, are *NO because this is not a single session location) 


Create the line description (SDLC nonswitched - New York) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGO) 
The name assigned to the line description is CHICAGO. 


RSRCNAME(LINO11) 
Specifies that the physical communications port named LINO11 is being defined. 
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Create the controller description in three-system network (New York) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example commana: 


CTLD(CHICAGO) 
The name assigned to the controller description is CHICAGO. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(CHICAGO) 
Specifies the name (CHICAGO) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
Specifies that the remote control-point name is CHICAGO. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In this example, the 
LCLCPNAME parameter specifies the name on the CHGNETA command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote location (CHICAGO) is an APPN networking node. 


Configure system B (Los Angeles) 

The following CL commands are used to define the configuration for the system that is identified as 
LOSANGEL (system B in [Figure 6 on page 37}. The examples show these commands as used within a CL 
program; You can also perform the configuration using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK R KER A KK EA KKK KKK KKK KKK KA KK AK KEK KKK ARE KAKA KEE AK KEK KKK AKER KK | 


/* */ 
/* MODULE: LACHENNN LIBRARY: PUBSCFGS «/ 
/* x*/ 
/* LANGUAGE: CL «/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN EN-NN-EN AS FOLLOWS: «/ 
/* x*/ 
/* */ 
/« NEWYORK / \ CHICAGO / \ LOSANGEL «/ 
/* \ / \ / x*/ 
/* x*/ 
/x (THIS IS LOSANGEL TO CHICAGO) «/ 
/* */ 
/* x/ 
/* x/ 
[KEK RK KKK KK EAR RRA K KKK KKK KKK KK KEK KKK KKK KAKA KKK KKK EA KKK EKER AKER KK | 
PGM 

[BRK R KEK KK EAR KEK KK ERK A KKK KKK KKK IKE KKK IKKE AK KEK AREA KEKE | 
/« LOSANGEL TO CHICAGO «/ 


[BRK KKK KKK AK KEK KKK KKK KK KKK KK ERK KEIRA AKAIKE KAKA AKER AREA KER | 
/* Change network attributes for LOSANGEL */ 
CHGNETA LCLNETID(APPN) LCLCPNAME (LOSANGEL) 
LCLLOCNAME(LOSANGEL) NODETYPE(*ENDNODE) 
NETSERVER((APPN CHICAGO) ) 
/* Create remote configuration list for LOSANGEL to 
New York */ 
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CRTCFGL TYPE(*APPNRMT) APPNRMTE( (NEWYORK APPN 
LOSANGEL NEWYORK APPN 3BD29F *YES *NO *NO *NO 
"RMT LOC of LOSANGEL')) 

/* Create line description for LOSANGEL to CHICAGO »*/ 

CRTLINSDLC LIND(CHICAGO) RSRCNAME(LINO41) 

/* Create controller description for LOSANGEL to 

CHICAGO */ 

CRTCTLAPPC CTLD(CHICAGO) LINKTYPE(*SDLC) LINE(CHICAGO) 
RMTNETID(APPN) RMTCPNAME (CHICAGO) 
STNADR(01) NODETYPE(*NETNODE) 

ENDPGM 


Change the network attributes (Los Angeles) in three-system network 
The Change Network Attributes (CHGNETA) command sets the attributes for the system within the 
network. The following attributes are for NEWYORK: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote location (CHICAGO in the example) 
must specify this name as the remote network identifier (RMTNETID) on the CRTCTLAPPC command. 


LCLCPNAME(LOSANGEL) 
Specifies that the name assigned to the local control point is LOSANGEL. The remote system 
specifies this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC 
command. 


LCLLOCNAME(LOSANGEL) 
The default local location name of this location is LOSANGEL. This name will be used for the device 
description that is created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (LOSANGEL) is an end node in the APPN network. 


NETSERVER((APPN CHICAGO)) 
Specifies the name of the network node (CHICAGO) and the name of the network (APPN) that serves 
this end node. These names are defined at the remote system on the CHGNETA command. 


Create the remote location configuration list (Los Angeles) 

You can also use the Create Configuration List (CRTCFGL) command to define the remote locations with 
special characteristics to the APPN support. In this example, location security is being used, and the 
following is defined at LOSANGEL: 


TYPE(*APPNRMT) 
Specifies that the entries being defined are remote locations. 


APPNRMTE((NEWYORK APPN LOSANGEL NEWYORK APPN 3BD29F *YES *NO *NO *NO ’RMT LOC 
of LOSANGEL’)) 
Specifies the remote location with which the local location can be paired. 


* The remote location name is NEWYORK 

e The remote network ID is APPN 

¢ The associated local location name is LOSANGEL 
* The remote control-point name is NEWYORK 

¢ The remote control-point network ID is also APPN 
* The password is 3BD29F 

* It is a secure location 


* The last two entries, locally controlled sessions and pre-established sessions, are *NO because this 
is not a single session location 


Create the line description (Los Angeles) 


The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 
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LIND(CHICAGO) 
The name assigned to the line description is CHICAGO. 


RSRCNAME(LINO41) 
Specifies that the physical communications port named LINO41. 


Create the controller description (Los Angeles) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(CHICAGO) 
The name assigned to the controller description is CHICAGO. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(CHICAGO) 
Specifies the name (CHICAGO) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
Specifies that the remote control-point name is CHICAGO. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the 
LCLCPNAME parameter on the CHGNETA command specifies the name at the remote system 
(CHICAGO). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote system (CHICAGO) is an APPN networking node. 


Configure system C (Chicago) 
The following CL commands define the configuration for the system that is identified as CHICAGO (system 
C in|Figure 6 on page 37). The example shows the commands as used within a CL program; the 


configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK KE RAK KEIR REAR KEK KK EAR KKK KEK KKK KKK AKI AKAIKE IKKE KAKA KER | 


/* x/ 
/* MODULE: CHNYCHLA LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL x/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN NETWORK: x/ 
/* x/ 
/* x/ 
/* NEWYORK / \ CHICAGO / \ LOSANGEL x/ 
/* x/ 
/* x/ 
/* (THIS IS CHICAGO TO NEWYORK AND LOSANGEL) x/ 
/* x/ 
/* x/ 
/* x/ 
OOO IOI IOI II III III II III III I I II II III IR IR IR I BK // 
PGM 


/* Change network attributes for CHICAGO ~*/ 
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CHGNETA LCLNETID(APPN) LCLCPNAME (CHICAGO) 
LCLLOCNAME (CHICAGO) NODETYPE (*NETNODE) 


[ REKRK REAR ERIK KEK K KEK AKER KEK AK K EA KKK KKK KEK KK EIA A KER AKKE KARE KK | 


/* CHICAGO TO NEWYORK */ 


[KERR KKK KK RAK KKK KK KKK KKK KKK KKK EAR AK KIA KKK IKKE AKIRA KER AK KE KARE KK | 


/* Create line description for CHICAGO to NEWYORK «/ 
CRTLINSDLC LIND(NEWYORK) RSRCNAME(LINOQ12) 
/* Create controller description for CHICAGO to 
NEWYORK */ 
CRTCTLAPPC CTLD(NEWYORK) LINKTYPE(*SDLC) LINE (NEWYORK) 
RMTNETID(APPN) RMTCPNAME (NEWYORK) 
STNADR(01) NODETYPE(*ENDNODE) 


[BRK RK ERA KER AK KEK KEK K KEK KEK AK KEK KKK KK AKKE AK KEK KKK IKKE AK KEKE | 


/* CHICAGO TO LOSANGEL */ 


[KEK RK RRR KER AK RRA K KKK K KKK KKK KK KKK KIKI K KKK KKK IKKE AKER AK KEK AKER KK | 
/* Create line description for CHICAGO to LOSANGEL «/ 
CRTLINSDLC LIND(LOSANGEL) RSRCNAME(LINO31) 
/* Create controller description for CHICAGO to 
LOSANGEL */ 
CRTCTLAPPC CTLD(LOSANGEL) LINKTYPE(*SDLC) LINE(LOSANGEL) 
RMTNETID(APPN) RMTCPNAME (LOSANGEL) 
STNADR(@1) NODETYPE (*ENDNODE) 
ENDPGM 


Change the network attributes (Chicago) in three-system network 
The Change Network Attributes (CHGNETA) command sets the attributes for the system within the 
network. The following attributes are defined for CHICAGO: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote locations (NEWYORK and 
LOSANGEL in the example, systems A and B in|Figure 6 on page 37) must specify this name as the 
remote network identifier (RMTNETID). 


LCLCPNAME(CHICAGO) 
Specifies that the name assigned to the local control point is CHICAGO. The remote system specifies 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(CHICAGO) 
The name of this location is CHICAGO. This name will be used for the device description that is 
created by the APPN support. 


NODETYPE(*NETNODE) 
Specifies that the local system (CHICAGO) is a networking node in the APPN network. 


Create the line description (Chicago to New York) in three-system network 
The line used in this example is an SDLC nonswitched line. The command used to create the line 
description is CRTLINSDLC. The parameters specified are: 


LIND(NEWYORK) 
The name assigned to the line description is NEWYORK. 


RSRCNAME(LINO12) 
Specifies the physical communications port named LINO12. 


Create the controller description (Chicago to New York) in three-system network 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(NEWYORK) 
The name assigned to the controller description is NEWYORK. 
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LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(NEWYORK) 
Specifies the name (NEWYORK) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(NEWYORK) 
Specifies that the remote control-point name (at NEWYORK) is NEWYORK. The name specified here 
must match the name that is specified at the remote system for the local control-point name. In the 
example, the LCLCPNAME parameter on the CHGNETA command specifies the name at the remote 
system (NEWYORK). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*ENDNODE) 
Specifies that the remote system (NEWYORK) is an APPN end node. 


Create the line description (Chicago to Los Angeles) 
The line used in this example is an SDLC nonswitched line. The Create Line Description (SDLC) 
(CRTLINSDLC) is command that is used to create the line. The parameters specified are: 


LIND(LOSANGEL) 
The name assigned to the line description is LOSANGEL. 


RSRCNAME(LINO31) 
Specifies the physical communications port named LINO31. 


Create the controller description (Chicago to Los Angeles) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(LOSANGEL) 
The name assigned to the controller description is LOSANGEL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(LOSANGEL) 
Specifies the name (LOSANGEL) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(LOSANGEL) 
Specifies that the remote control-point name (at LOSANGEL) is LOSANGEL. The name specified here 
must match the name that is specified at the remote system for the local control-point name. In the 
example, the LCLCPNAME parameter of the Change Network Attributes (CHGNETA) command 
specifies the name at the remote system (LOSANGEL). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 
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NODETYPE(*ENDNODE) 
Specifies that the remote system (LOSANGEL) is an APPN end node. 


Two APPN networks with different network IDs linked together 
Figure 7 shows two APPN networks that are linked together by network nodes. 


The network with the LCLNETID of NEWNET is a simple connection of one end node to one network 
node. Network node B could act as a network server providing routing services for node A. Although there 
are no other nodes in the NEWNET network, there is a need for nodes A and B to communicate with the 
nodes in network APPN. To accomplish this, network node B is connected to network node NN1 in the 
APPN network. Node B must have a line description and a controller description created to identify node 
A, and a line description and a controller description to identify node NN1. 


The network with the LCLNETID of APPN is similar to NEWNET; with the exception that NN2 is a network 
node instead of an end node. In order for NN1 and NN2 to communicate with the nodes in NEWNET, NN1 
must have two line descriptions, and two controller descriptions created. These identify both node B and 
node NN2. 


After node B and node NN1 are identified to each other as adjacent nodes, all nodes in either network can 
communicate through nodes B and NN1. 


End Hode WNetrork Node NetwormNode Netvork Node 


: a ~ 


Hew York Detroit Chicago Minneapolis 
RWES051-0 
Figure 7. Two APPN networks linked by network nodes 


Each list below represents a city within the network in Figure 7 above. See the links in each list to 
determine the configuration requirements for each system. 


New York 

* |“Configure system: New York” on page 4 

* |“Change the network attributes (New York) for two APPN networks with different IDs” on page 46 
* |“Create the line description (New York)” on page 47| 

* |“Create the controller description (New York) for two-system network with different IDs” on page 4 


, 


Detroit 

¢ |“Configure system B (Detroit)” on page 48 

* |“Change the network attributes (Detroit)” on page 48 

* |“Create the line description (Detroit to New York)” on page 49 

* |“Create the controller description (Detroit to New York)” on page 49) 
* |“Create the line description (Detroit to Chicago)” on page 49 

* |“create the controller description (Detroit to Chicago)” on page 49 


Chicago 
* |“Configure system NN1 (Chicago)” on page 50 
* |“Change the network attributes (Chicago) for two-system APPN network with different IDs” on page 51 
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* |“Create the line description (Chicago to Minneapolis) for two-system APPN network with different IDs” 
on page 51 
“Create the controller description (Chicago to Minneapolis) for two-system APPN network with different 


IDs” on page 51 
“Create the line description (Chicago to Detroit)” on page 52 
“Create the controller description (Chicago to Detroit)” on page 52 


“Configure NN2 (Minneapolis)” on page 52 
“Change the network attributes (Minneapolis) for two networks with different ID 
“Create the line description (Minneapolis to Chicago)” on page 53 
“Create the controller description (Minneapolis to Chicago)” on page 53 


s” on page 53 


Configure system: New York 
The following CL commands are used to define the configuration for the system identified as NEWYORK 
(system A in|Figure 7 on page 45). The examples show these commands as used within a CL program; 


the configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK R KER A KK AK KER KKK KEK KKK KK EAR EIR K KARE KKK IKKE AK KEK KKK A KEKE | 


/* x/ 
/* MODULE: NYCINT LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL x/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN EN-NN AS FOLLOWS: x/ 
/* x/ 
/* x/ 
/* NEWYORK / \ DETROIT x/ 
/* \ / x/ 
/* x/ 
/* (THIS IS NEWYORK TO DETROIT) x/ 
/* x/ 
/* x/ 
/* x/ 
OIG IOI III III III II I III II I II III IIR I RI IR RR  /| 
PGM 

TTT TITTLE TTT TE TTL T TELE EEE EEE EEE RCE E ELECT L EERE EEE 
/* NEWYORK TO DETROIT x/ 


[BRK R KER A KK EAR KEIR KKK KEK KKK KKK KKK KKK KKK KEI EA KEIR AKER | 
/* Change network attributes for NEWYORK ~*/ 
CHGNETA LCLNETID(NEWNET) LCLCPNAME (NEWYORK) 
LCLLOCNAME (NEWYORK) NODETYPE(*ENDNODE) 
NETSERVER((NEWNET DETROIT)) 
/* Create line description for NEWYORK to DETROIT «/ 
CRTLINSDLC LIND(DETROIT) RSRCNAME(LINO11) 
/* Create controller description for NEWYORK to 
DETROIT ~/ 
CRTCTLAPPC CTLD(DETROIT) LINKTYPE(*SDLC) LINE(DETROIT) 
RMTNETID(NEWNET) RMTCPNAME (DETROIT) 
STNADR(01) NODETYPE(*NETNODE) 
ENDPGM 


Change the network attributes (New York) for two APPN networks with different 
IDs 

The Change Network Attributes (CHGNETA) command set the attributes for the system within the network. 
The following attributes are defined for NEWYORK: 
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LCLNETID(NEWNET) 
Specifies that the name of the local network is NEWNET. The remote location (DETROIT in the 
example, system B in [Figure 7 on page 45), must specify this name as the remote network identifier 
(RMTNETID) on the CRTCTLAPPC command. 


LCLCPNAME(NEWYORK) 
Specifies that the name assigned to the local control point is NEWYORK. The remote system specifies 
this name as the remote control-point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(NEWYORK) 
The default local location name of this location is NEWYORK. This name is used for the device 
description that is created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (NEWYORK) is an end node in the NEWNET network. 


NETSERVER((NEWNET DETROIT)) 
Specifies the name of the network node (DETROIT) and the name of the network (NEWNET) that 
serves this end node. These names are defined at the remote system on the CHGNETA command. 


Create the line description (New York) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(DETROIT) 
The name assigned to the line description is DETROIT. 


RSRCNAME(LINO11) 
Specifies the physical communications port named LINO11. 


Create the controller description (New York) for two-system network with different 
IDs 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(DETROIT) 
The name assigned to the controller description is DETROIT. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(DETROIT) 
Specifies the name (DETROIT) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(NEWNET) 
The name of the network in which the remote control point resides is NEWNET. 


RMTCPNAME(DETROIT) 
Specifies that the remote control-point name is DETROIT. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the 
LCLCPNAME parameter on the CHGNETA command specifies the name at the remote system 
(DETROIT). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote location (DETROIT) is an APPN networking node. 
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Configure system B (Detroit) 
The following CL commands define the configuration for the system that is identified as DETROIT (system 
B in|Figure 7 on page 45). The example shows the commands as used within a CL program; the 


configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[ REK KKK KKK RIKKI KKK KK KKK KKK KKK KK IK KKK KKK KKK KAKA KKK AKER AKER KK | 


/* x/ 
/* MODULE: DETRINT LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL x/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN NETWORK: x/ 
/* x/ 
/* x/ 
/* NEWYORK / \ DETROIT / \ CHICAGO x/ 
/* \ / \ / x/ 
/* x/ 
/* (THIS IS DETROIT TO NEWYORK AND CHICAGO) x/ 
/* x/ 
/* x/ 
/* x/ 
TTT TTT TELL TET LTTE LTTE LEE EE EEE TELE ELEE EERE EEE 
PGM 


/* Change network attributes for DETROIT */ 
CHGNETA LCLNETID(NEWNET) LCLCPNAME (DETROIT) 
LCLLOCNAME (DETROIT) NODETYPE(*NETNODE) 
[BRK R KEK K KEIR KEK KK ERK KKK KK EAR AK KIKI KKK IA IKEA KK EAA AK ERK | 
/* DETROIT TO NEWYORK x/ 
[RRR RK KKK KER KKK KKK KK KKK KKK KKK KK IK KKK KKK KKK IKK A KKK KA KER KK | 
/* Create line description for DETROIT to NEWYORK «/ 
CRTLINSDLC LIND(NEWYORK) RSRCNAME(LINO12) 
/* Create controller description for DETROIT to 
NEWYORK */ 
CRTCTLAPPC CTLD(NEWYORK) LINKTYPE(*SDLC) LINE(NEWYORK) 
RMTNETID(NEWNET) RMTCPNAME (NEWYORK) 
STNADR(@1) NODETYPE(*ENDNODE) 
[BRK KKK KKK RAK K KKK KKK KKK KKK IK KKK KK IK KKK KKK KKK KKK AK KEK KKK A KER KK | 
/* DETROIT TO CHICAGO */ 
[KEK RK ERK KK EAA KKK KEK KKK KKK KKK KKK KK KKK AKA KKK KAKA KK EAR A KER KK | 
/* Create line description for DETROIT to CHICAGO «/ 
CRTLINSDLC LIND(CHICAGO) RSRCNAME(LINO31) 
/* Create controller description for DETROIT to 
CHICAGO */ 
CRTCTLAPPC CTLD(CHICAGO) LINKTYPE(*SDLC) LINE(CHICAGO) 
RMTNETID(APPN) RMTCPNAME (CHICAGO) 
STNADR(@1) NODETYPE(*NETNODE) 
ENDPGM 


Change the network attributes (Detroit) 
The Change Network Attributes (CHGNETA) command sets the attributes for the system within the 
network. The following attributes are defined for DETROIT: 


LCLNETID(NEWNET) 
Specifies that the name of the local network is NEWNET. The remote locations (NEWYORK and 
CHICAGO in the example program, systems A and NN1 in|Figure 7 on page 45} must specify this 
name as the remote network identifier (RMTNETID). 


LCLCPNAME(DETROIT) 
Specifies that the name assigned to the local control point is DETROIT. The remote system specifies 
this name as the remote control-point name (RMTCPNAME) on the CRTCTLAPPC command. 
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LCLLOCNAME(DETROIT) 
The name of this location is DETROIT. This name is used for the device description that is created by 
the APPN support. 


NODETYPE(*NETNODE) 
Specifies that the local system (DETROIT) is a networking node in the NEWNET network. 


Create the line description (Detroit to New York) 
The line used in this example is an SDLC nonswitched line. The command used to create the line 
description is CRTLINSDLC. The parameters specified are: 


LIND(NEWYORK) 
The name assigned to the line description is NEWYORK. 


RSRCNAME(LINO12) 
Specifies the physical communications port named LINO12. 


Create the controller description (Detroit to New York) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 


CTLD(NEWYORK) 
The name assigned to the controller description is NEWYORK. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(NEWYORK) 
Specifies the name (NEWYORK) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(NEWNET) 
The name of the network in which the remote control point resides is NEWNET. 


RMTCPNAME(NEWYORK) 
Specifies that the remote control-point name is NEWYORK. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the 
LCLCPNAME parameter on the CHGNETA command specifies the name at the remote system 
(NEWYORK). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*ENDNODE) 
Specifies that the remote system (NEWYORK) is an APPN end node. 


Create the line description (Detroit to Chicago) 
The line used in this example is an SDLC nonswitched line. The Create Line Description (SDLC) 
(CRTLINSDLC) command is used to create the line. The parameters specified are: 


LIND(CHICAGO) 
The name assigned to the line description is CHICAGO. 


RSRCNAME(LINO31) 
Specifies the physical communications port named LINO31. 


create the controller description (Detroit to Chicago) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command defines the attributes of the controller. The example command 
defines the following attributes: 
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CTLD(CHICAGO) 
The name assigned to the controller description is CHICAGO. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(CHICAGO) 
Specifies the name (CHICAGO) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
Specifies that the remote control-point name is CHICAGO. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the 
LCLCPNAME parameter of the Change Network Attributes (CHGNETA) command specifies the name 
at the remote system (CHICAGO). 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote system (CHICAGO) is an APPN network node. 


Configure system NN1 (Chicago) 
The following CL commands are used to define the configuration for the system that is identified as 


CHICAGO (system NN1 in|Figure 7 on page 45). The examples show these commands as used within a 


CL program; the configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK KKK RAK KEAK KERR KER KKK KKK AK KEK KKK KKK AKI KKK KAKA KEKE A KEKE | 


/* x/ 
/* MODULE: CHICINT LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL */ 
/* x/ 
/* FUNCTION: CONFIGURES APPN NETWORK: x/ 
/* x/ 
/* THIS IS: CHICAGO TO MPLS x/ 
/* CHICAGO TO DETROIT x/ 
/* x/ 
/* x/ 
/* x/ 
/* x/ 
TITTLE ETT T ETT ETT LTTE EEE EEE EEE EEE EERE TELE LEEEEEEEE ELLE 
PGM 


/* Change network attributes for CHICAGO */ 
CHGNETA LCLNETID(APPN) LCLCPNAME(CHICAGO) + 
LCLLOCNAME (CHICAGO) NODETYPE(*NETNODE) 
[ REKRKK KKK KEI K KIRKE KKK KKK KKK KK AK KEI KKK KAKA KKK KKK AK KEK KEK A KEKE | 
/* CHICAGO TO MPLS x/ 
[KEK KERR KK ERK A KKK KK KKK KKK KKK KKK KKK IKK KK KKK KKK AK KEK EKER A KEKE | 
/* Create nonswitched line description for CHICAGO to MPLS */ 
CRTLINSDLC LIND(MPLSL) RSRCNAME(LINO21) 
/* Create controller description for CHICAGO to MPLS «/ 
CRTCTLAPPC CTLD(MPLSL) LINKTYPE(*SDLC) LINE(MPLSL) + 
RMTNETID(APPN) RMTCPNAME(MPLS) + 
STNADR(01) NODETYPE(*NETNODE) 
[BERR KERR KEKE IKKE RK KKK KEK KKK KKK AK KEK IKE KAKI AIK E AK KEK AREA KERR | 
/* CHICAGO TO DETROIT */ 


[RHR KERR KK EAA KEK KKK KK KKK KKK KKK KKK KKK KAKA KKK IKKE AK KEK AKER AKER KK | 
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/* Create nonswitched line description for CHICAGO to x/ 
DETROIT */ 
CRTLINSDLC LIND(DETROIT) RSRCNAME(LINO21) 
/* Create controller description for CHICAGO to 
DETROIT */ 
CRTCTLAPPC CTLD(DETROIT) LINKTYPE(*SDLC) LINE(DETROIT) + 
RMTNETID(NEWNET) RMTCPNAME(DETROIT) + 
STNADR(01) NODETYPE(*NETNODE) 
ENDPGM 


Change the network attributes (Chicago) for two-system APPN network with 
different IDs 

The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for the CHICAGO system. 


LCLNETID(APPN) 
The name of the local network is APPN. The remote system (MPLS in the example program, NN2 in 
must specify this name as the remote network identifier (RMTNETID) on the 
CRICTLAPPC command. 


LCLCPNAME(CHICAGO) 
The name assigned to the local control point is CHICAGO. The remote systems specify this name as 
the remote control-point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(CHICAGO) 
The default local location name is CHICAGO. This name is used for the device description that is 
created by the APPN support. 


NODETYPE(*NETNODE) 
The local system (CHICAGO) is an APPN network node. 


Create the line description (Chicago to Minneapolis) for two-system APPN network 
with different IDs 

The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLSL) 
The name assigned to the line description is MPLSL. 


RSRCNAME(LINO21) 
The physical communications port named LINO21 is defined. 


Create the controller description (Chicago to Minneapolis) for two-system APPN 
network with different IDs 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(MPLSL) 
The name assigned to the controller description is MPLSL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


LINE(MPLSL) 
The name of the line description to which this controller is attached is MPLSL. This value must match 
a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 
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RMTCPNAME(MPLS) 
The remote control-point name is MPLS. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the name is specified 
at the remote system (MPLS) by the LCLCPNAME parameter on the Change Network Attributes 
(CHGNETA) command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
The remote system (MPLS) is an APPN network node. 


Create the line description (Chicago to Detroit) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(DETROIT) 
The name assigned to the line description is DETROIT. 


RSRCNAME(LINO21) 
The physical communications port named LINO21 is defined. 


Create the controller description (Chicago to Detroit) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(DETROIT) 
The name assigned to the controller description is DETROIT. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


LINE(DETROIT) 
The name of the line description to which this controller is attached is DETROIT. This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(NEWNET) 
The name of the network in which the remote control point resides is NEWNET. 


RMTCPNAME(DETROIT) 
The remote control-point name is DETROIT. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the name is specified 
at the remote system (DETROIT) by the LCLCPNAME parameter on the Change Network Attributes 
(CHGNETA) command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
The remote system (DETROIT) is an APPN network node. 


Configure NN2 (Minneapolis) 
The following example program shows the CL commands used to define the configuration for the system 


that is identified as MPLS (NN2 in|Figure 7 on page 45). The example shows these commands used within 


a CL program; the configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 
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[KEK RK KKK RAK RRA K KAR KKK KKK KKK IKK IK KKK KKK KKK KK IKEA KER AK KEK ARE | 


/* */ 
/* MODULE: MPLSINT LIBRARY: PUBSCFGS */ 
/* */ 
/* LANGUAGE: CL */ 
/* x/ 
/* FUNCTION: CONFIGURES APPN NETWORK: */ 
/* */ 
/* THIS IS: MPLS TO CHICAGO (nonswitched) */ 
/* x/ 
/* */ 
[ REKRK ERA RRR AK KER KKK AKER KERIKERI KK AKER I KIKI KK AKK EA AREA | 
PGM 


/* Change network attributes for MPLS «/ 
CHGNETA LCLNETID(APPN) LCLCPNAME(MPLS) + 
LCLLOCNAME (MPLS) NODETYPE(*NETNODE) 


[BRK K ERR RRR AK KER KKK KK EIR KEK AKKE KKK AK KIA KKK KAKA KIKI KKK KKK AKER KK | 


/* MPLS TO CHICAGO x/ 


[RRR RK KKK KEIR KKK KKK KKK KKK KKK KKK AK KIA KKK KKK KKK EA KKK KEK K KEKE | 
/* Create line description for MPLS to CHICAGO */ 
CRTLINSDLC LIND(CHICAGO) RSRCNAME(LINO22) 
/* Create controller description for MPLS to CHICAGO «/ 
CRTCTLAPPC CTLD(CHICAGO) LINKTYPE(*SDLC) LINE(CHICAGO) + 
RMTNETID(APPN) RMTCPNAME(CHICAGO) + 
STNADR(01) NODETYPE(*NETNODE) 
ENDPGM 


Change the network attributes (Minneapolis) for two networks with different ID’s 
The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for the MPLS system, and these attributes apply to all 
connections in the network for this network node: 


LCLNETID(APPN) 
The name of the local network is APPN. The remote systems (CHICAGO in the example program, 
NN1 in|Figure 7 on page 45) must specify this name as the remote network identifier (RMTNETID) on 
the CRTCTLAPPC command. 


LCLCPNAME(MPLS) 
The name assigned to the local control point is MPLS. The remote system specifies this name as the 
remote control-point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(MPLS) 
The default local location name is MPLS. This name is used for the device description that is created 
by the APPN support. 


NODETYPE(*NETNODE) 
The local system (MPLS) is an APPN network node. 


Create the line description (Minneapolis to Chicago) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGO) 
The name assigned to the line description is CHICAGO. 


RSRCNAME(LINO22) 
The physical communications port named LINO22. 


Create the controller description (Minneapolis to Chicago) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller, and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 
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CTLD(CHICAGO) 
The name assigned to the controller description is CHICAGO. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line that is defined by a create line description 
command. 


LINE(CHICAGO) 
The name of the line description to which this controller is attached is CHICAGO. This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
The remote control-point name is CHICAGO. The name specified here must match the name that is 
specified at the remote system for the local control-point name. In the example, the name is specified 
at the remote system (CHICAGO) by the LCLCPNAME parameter on the Change Network Attributes 
(CHGNETA) command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
The remote system (CHICAGO) is an APPN network node. 


Multiple iSeries systems using APPN 

The following sections describe configuration for the network that is shown in Figure 8. In this network, 
seven iSeries systems are configured to communicate, using the APPN functions. Network attributes, line 
descriptions, APPC controller descriptions, and APPC device descriptions are created, either automatically 
or manually, to set up this network. 
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Figure 8. Multiple iSeries systems using APPN 


Each list below represents a city within the network in Figure 8 above. See the links in each list to 
determine the configuration requirements for each system. 


New York 

“Configure end node 1 (New York)” on page 57 
“Change the network attributes (New York) in multiple-system network” on page 57 
“Create the remote location configuration list (New York)” on page 58 
“Create the line description (New York to Chicago)” on page 58 
“Create the controller description (New York to Chicago)” on page 58 
* |“Create the line description (New York to Minneapolis)” on page 59 

* |“Create the controller description (New York to Minneapolis)” on page 59 


Chicago 

: 

* |“Change the network attributes (Chicago) in multiple-system network” on page 61 

* |“Create the line description (Chicago to New York)” on page 61 

¢ |“Create the controller description (Chicago to New York)” on page 61 

* |“Create the line description (Chicago to Minneapolis) in multiple-system network” on page 62 
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* |“Create the controller description (Chicago to Minneapolis) in multiple-system network” on page 62 


* |“Create line description B (Chicago to Minneapolis) in multiple-system network” on page 63 
* |“Create controller description B (Chicago to Minneapolis) in multiple-system network” on page 63 


Minneapolis 

“Configure network node 2 (Minneapolis) in multiple-system network” on page 64 
“Change the network attributes (Minneapolis) in multiple-system network” on page 65) 
“Create the line description (Minneapolis to New York, switched)” on page 66 
“Create the controller description (Minneapolis to New York, switched)” on page 6 
“Create the line description A (Minneapolis to Chicago)” on page 67 
“Create the controller description (Minneapolis to Chicago, nonswitched)” on page 67 
“Create the line description B (Minneapolis to Chicago)” on page 67 
“Create the controller description (Minneapolis to Chicago, switched)” on page 68 
“Create the line description (Minneapolis to Los Angeles, switched)” on page 69 
* |“Create the controller description (Minneapolis to Los Angeles, switched)” on page 69 
* |“Create the line description (Minneapolis to token-ring network)” on page 70 


* |“Create the controller description (Minneapolis to Purchasing, token-ring network)” on page 70 
* |“Create the controller description (Minneapolis to Distribution, token-ring network)” on page 71 


* |“Create the controller description (Minneapolis to Payroll, token-ring network)” on page 71 
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Los Angeles 

* |“Configure end node 2 (Los Angeles)” on page 72 

* |“Change the network attributes (Los Angeles) in multiple-system network” on page 73 
¢ |“Create the line description (Los Angeles to Minneapolis)” on page 73 

¢ |“Create the controller description (Los Angeles to Minneapolis)” on page 73 


Purchasing 

* |“Configure end node A (Purchasing)” on page 74 

* |“Change the network attributes (Purchasing)” on page 75 

* |“Create the remote location configuration list (Purchasing)” on page 75 

* |“Create the line description (Purchasing to token-ring network)” on page 76 

* |“Create the controller description (Purchasing to Minneapolis, token-ring network)” on page 76 
* |“Create the controller description (Purchasing to Distribution, token-ring network)” on page 77, 


Distribution 

“Configure end node B (Distribution)” on page 77 
“Change the network attributes (Distribution)” on page 78 
“Create the line description (Distribution to token-ring network)” on page 79 
“Create the controller description (Distribution to Minneapolis, token-ring network)” on page 79 
“Create the controller description (Distribution to Purchasing, token-ring network)” on page 79 


“Configure low entry networking end node 1 (Payroll)” on page 80 
“Create the line description (Payroll to token-ring network)” on page 81 
“Create the controller description (Payroll to token-ring network)” on page 81 
“Create the APPC device (Payroll to New York)” on page 82 
* |“Create the APPC device (Payroll to Los Angeles)” on page 82 
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* |“Create the APPC device (Payroll to Minneapolis)” on page 83 


Configure 


The following CL commands are used to define the configuration for the system that is identified as 


end node 1 (New York) 


NEWYORK. The example shows the commands used within a CL program; the configuration can also be 
performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK K ERA KK RAK KER KKK AKER KEK AK KEK KK IKK IKKE IKKE KAKA KK A KEK K REA KE | 


/* 

/* MODULE: 
/* 

/* LANGUAGE: 
/* 

/* FUNCTION: 
/* 

/* 

/* 

/* 

/* 

/* 


*/ 

NEWYORK LIBRARY: PUBSCFGS */ 
x/ 

CL */ 
*/ 

CONFIGURES APPN NETWORK: */ 
x/ 

THIS IS: NEWYORK TO CHICAGO (nonswitched) */ 
NEWYORK TO MPLS (switched) */ 

*/ 

*/ 

x/ 


[BRK K ERA KK RAK KEIRA KKK KKK AK KEK KKK KA KKK KKK AKI EA KEE AK KEI AKER KK | 


PGM 


[BRK K ERA KEIR KEK KR AKKEKKKEKA KK K KK IKKA KKK KKK EAR IKEA KEE AK KE AAR K KE | 


/* 


NEWYORK TO CHICAGO (nonswitched) */ 


[RRR RK RRR KK RAK KKK K KKK KKK KKK KKK EA K KIKI KKK IK IKEA KER AK KEK AKER KK | 


/* Change network attributes for NEWYORK */ 
CHGNETA LCLNETID(APPN) LCLCPNAME (NEWYORK) 
LCLLOCNAME (NEWYORK) NODETYPE(*ENDNODE) 
NETSERVER((APPN CHICAGO) (APPN MPLS)) 
/* Create remote configuration list for NEWYORK to 
Los Angeles */ 
CRTCFGL TYPE(*APPNRMT) APPNRMTE((LOSANGEL APPN 
NEWYORK LOSANGEL APPN 3BD29F *YES *NO *NO *NO 
"RMT LOC of NEWYORK')) 
/* Create nonswitched line description for NEWYORK to */ 
CHICAGO CRTLINSDLC LIND(CHICAGOL) RSRCNAME(LINO11) 
/* Create controller description for NEWYORK to 
CHICAGO */ 
CRTCTLAPPC CTLD(CHICAGOL) LINKTYPE(*SDLC) LINE(CHICAGOL) 
RMTNETID(APPN) RMTCPNAME (CHICAGO) 
STNADR(@1) NODETYPE(*NETNODE) 


[RRR RK RRR KK RAK KKK KK KKK KKK KKK A KKK KKK KKK A KKK KKK AKIRA KEK A KK E KARE KK | 


/* 


NEWYORK TO MPLS (switched) x/ 


[KEK RK RRR KK AK KEK KKK IKK KKK KKK KK KEK KK AK KKK KKK KIKI AKER AK KEK AKER KK | 


ENDPGM 


Change the network attributes (New York) in multiple-system network 
The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for NEWYORK, and these attributes apply to all 


/* Create switched line description NEWYORK to MPLS «/ 
CRTLINSDLC LIND(MPLSS) RSRCNAME(LINO12) CNN(*SWTPP) 
AUTOANS(*NO) STNADR(01) COSTCNN(128) 
COSTBYTE (128) 
/* Create controller description for NEWYORK to MPLS «/ 
CRTCTLAPPC CTLD(MPLSS) LINKTYPE(*SDLC) SWITCHED(*YES) 
SWTLINLST(MPLSS) RMTNETID(APPN) 
RMTCPNAME (MPLS) INLCNN(*ANS) 
CNNNBR(6125551234) STNADR(01) 
CPSSN(*NO) NODETYPE(*NETNODE) 


connections in the network for this end node: 
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LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote location (MINNEAPOLIS in the 
example, NN2 in the [Figure 8 on page 55) must specify this name as the remote network identifier 
(RMTNETID) on the CRTCTLAPPC command. 


LCLCPNAME(NEWYORK) 
Specifies that the name assigned to the local control point is NEWYORK. The remote systems specify 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(NEWYORK) 
The default local location name is NEWYORK. This name will be used for the device description that 
is created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (NEWYORK) is an APPN end node. 


NETSERVER((APPN CHICAGO) 
Specifies that network nodes CHICAGO (NN1) and MPLS (NN2) are both potential network node 
servers for this end point. Both network node servers are in the same (APPN) network. 


Create the remote location configuration list (New York) 

The Create Configuration List (CRTCFGL) command is also used to define the remote locations with 
special characteristics to the APPN support. In this example, location security is being used, and the 
following is defined at NEWYORK: 


TYPE(*APPNRMT) 
Specifies that the entries being defined are remote locations. 


APPNRMTE((LOSANGEL APPN NEWYORK LOSANGEL APPN 3BD29F *YES *NO *NO *NO ’RMT 
LOC of NEWYORK’)) 
Specifies the remote location with which the local location can be paired. 


* The remote location name is LOSANGEL 

* The remote network ID is APPN 

* The associated local location name is NEWYORK 
* The remote control-point name is LOSANGEL 

¢ The remote control point network ID is also APPN 
* The password is 3BD29F 

* It is a secure location 


* Itis not a single session location. The last two entries, locally controlled sessions and 
pre-established sessions, are *NO because this is not a single session location. 


Create the line description (New York to Chicago) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGOL) 
The name assigned to the line description is CHICAGOL. 


RSRCNAME(LINO11) 
Specifies that the physical communications port named LINO11 is being defined. 


Create the controller description (New York to Chicago) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(CHICAGOL) 
The name assigned to the controller description is CHICAGOL. 
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LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(CHICAGOL) 
Specifies the name (CHICAGOL) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
Specifies that the remote control-point name is CHICAGO. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (CHICAGO) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote location (CHICAGO) is an APPN networking node. 


Create the line description (New York to Minneapolis) 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLSS) 
The name assigned to the line description is MPLSS. 


RSRCNAME(LINO12) 
Specifies that the physical communications port named LINO12 is being defined. 


CNN(*SWTPP) 
Specifies that this is a switched line connection. 


AUTOANS(*NO) 
Specifies that this system will not automatically answer an incoming call. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


COSTCNN(128) 
The relative cost of being connected to this line is 128, with 0 being the lowest cost and 255 the 
highest. The class of service use this for route selection. 


COSTBYTE(128) 
The relative cost of transferring a byte of data across this line is 128, with 0 being the lowest cost and 
255 the highest. This is used for route selection by the class of service. 


Create the controller description (New York to Minneapolis) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example commana: 


CTLD(MPLSS) 
The name assigned to the controller description is MPLSS. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 
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SWITCHED(*YES) 
Specifies that this controller is attached to a switched SDLC line. 


SWTLINLST(MPLSS) 
Specifies the name (MPLSS) of the line description (for switched lines) that this controller can be 
attached to. In the example, there is only one line (MPLSS). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote location resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system (MPLSS) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


INLCNN(*ANS) 
Specifies that the initial connection is made by the iSeries system answering an incoming call. 


CNNNBR(6125551234) 
The connection (telephone) number for the remote controller is 6125551234. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


CPSSN(*NO) 
Control point sessions are not supported with this node. 


NODETYPE(*NETNODE) 
Specifies that the remote location (MPLS) is an APPN networking node. 


Configure network node 1 (Chicago) 

The following CL commands are used to define the configuration for the system named as CHICAGO 
(NN1). The example shows the commands as used within a CL program; the configuration can also be 
done using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[ REK RK K RAK K RIKKI KKK KKK KKK KKK KKK IK KAKA KKK KAKA KEKE KARE KK | 


/* */ 
/* MODULE: CHICAGO LIBRARY: PUBSCFGS */ 
/* */ 
/* LANGUAGE: CL */ 
/* */ 
/* FUNCTION: CONFIGURES APPN NETWORK: */ 
/* */ 
/* THIS IS: CHICAGO TO NEWYORK (nonswitched) «/ 
/* CHICAGO TO MPLS (nonswitched) */ 
/* CHICAGO TO MPLS (switched) */ 
/* */ 
/* */ 
/* */ 
/* */ 
[KEK RK KKK KEI KKK AK KKK KKK KKK KK EAR K KKK KKK KKK KKK K KEKE RAKE KK | 
PGM 


/* Change network attributes for CHICAGO «/ 
CHGNETA LCLNETID(APPN) LCLCPNAME (CHICAGO) 
LCLLOCNAME (CHICAGO) NODETYPE(*NETNODE) 

[ REKRK ERK K KEI K KAR KEK KK KKK KKK KKK KK EIR KKK KKK KKK IKKE AK KEK AKER AKER KK | 
/* CHICAGO TO NEWYORK x/ 
[BERR KEK KK EAK KEIR K ERK KKEK KKK KKK AKA KEK AKA KKK KEK A KER | 

/* Create line description for CHICAGO to NEWYORK «/ 

CRTLINSDLC LIND(NEWYORK) RSRCNAME(LINO12) 

/* Create controller description for CHICAGO to 
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NEWYORK */ 
CRTCTLAPPC CTLD(NEWYORK) LINKTYPE(*SDLC) LINE (NEWYORK) 
RMTNETID(APPN) RMTCPNAME (NEWYORK) 
STNADR(Q1) NODETYPE (*ENDNODE) 


[RRR RK RRR KER AK RRA K KKK K KKK KKK KK KEK KK IK KIA KKK KKK KIRKE IKK A AKER AKER KK | 


/* CHICAGO TO MPLS (nonswitched) */ 


[RRR RK ERA KER AK KEK KKK KKK IK KEK AK KEK KEI KKIA KKK KEI KIKI KEE AKER KARE | 
/* Create nonswitched line description for CHICAGO to MPLS */ 
CRTLINSDLC LIND(MPLSL) RSRCNAME (LINO21) 
/* Create controller description for CHICAGO to MPLS «/ 
CRTCTLAPPC CTLD(MPLSL) LINKTYPE(*SDLC) LINE(MPLSL) 
RMTNETID(APPN) RMTCPNAME (MPLS) 
STNADR(01) NODETYPE(*NETNODE) 


[RRR K KAKA KKK AK KK K KK KKK KKK KKK AK KIKI A KKK KKK IKKE AKER IKKE KARE KK | 


/* CHICAGO TO MPLS (switched) */ 
[ REKRK ERA KER AK KEK KKK KKK KKK KK ERK KEIRA KKK KAKI KIRA KEE AK KEK AKER KK | 
/* Create switched line description for CHICAGO to MPLS */ 
CRTLINSDLC LIND(MPLSS) RSRCNAME(LINO22) CNN(*SWTPP) 
STNADR(@1) AUTOANS(*NO) COSTCNN(128) 
COSTBYTE (128) 
/* Create controller description for CHICAGO to MPLS «/ 
CRTCTLAPPC CTLD(MPLSS) LINKTYPE(*SDLC) SWITCHED(*YES) 
SWTLINLST(MPLSS) RMTNETID(APPN) 
RMTCPNAME (MPLS) INLCNN(*DIAL) 
CNNNBR(6125551111) STNADR(01) 
TMSGRPNBR(3) NODETYPE(*NETNODE) 
ENDPGM 


Change the network attributes (Chicago) in multiple-system network 

The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for CHICAGO and these attributes apply to all 
connections in the network for this network node. 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote location (MPLS in the example, 
NN2 in the figure, and NEWYORK, EN1 in the figure) must specify this name as the remote network 
identifier (RMTNETID) on the CRTCTLAPPC command. 


LCLCPNAME(CHICAGO) 
Specifies that the name assigned to the local control point is CHICAGO. The remote systems specify 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(CHICAGO) 
The default local location name is CHICAGO. This name will be used for the device description that is 
created by the APPN support. 


NODETYPE(*NETNODE) 
Specifies that the local system (CHICAGO) is an APPN network node. 


Create the line description (Chicago to New York) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(NEWYORK) 
The name assigned to the line description is NEWYORK. 


RSRCNAME(LINO12) 
Specifies that the physical communications port named LINO12 is being defined. 


Create the controller description (Chicago to New York) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example command: 
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CTLD(NEWYORK) 
The name assigned to the controller description is NEWYORK. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(NEWYORK) 
Specifies the name (NEWYORK) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(NEWYORK) 
Specifies that the remote control-point name is NEWYORK. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (NEWYORK) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*ENDNODE) 
Specifies that the remote location (NEWYORK) is an APPN end node. 


Create the line description (Chicago to Minneapolis) in multiple-system network 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLSL) 
The name assigned to the line description is MPLSL. 


RSRCNAME(LINO21) 
Specifies that the physical communications port named LINO21 is being defined. 


Create the controller description (Chicago to Minneapolis) in multiple-system 
network 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example commana: 


CTLD(MPLSL) 
The name assigned to the controller description is MPLSL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(MPLSL) 
Specifies the name (MPLSL) of the line description to which this controller is attached. This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system (NEWYORK) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 
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STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote location (MPLS) is an APPN networking node. 


Create line description B (Chicago to Minneapolis) in multiple-system network 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLSS) 
The name assigned to the line description is MPLSS. 


RSRCNAME(LINO22) 
Specifies that the physical communications port named LINO22 is being defined. 


CNN(*SWTPP) 
Specifies that this is a switched line connection. 


STNADR(01) 
The address assigned to the local system is hex 01. 


AUTOANS(*NO) 
Specifies that this system will not automatically answer an incoming call. 


COSTCNN(128) 
The relative cost of being connected to this line is 128, with 0 being the lowest cost and 255 the 
highest. The class of service use this for route selection. 


COSTBYTE(128) 
The relative cost of transferring a byte of data across this line is 128, with 0 being the lowest cost and 
255 the highest. This is used for route selection by the class of service. 


Create controller description B (Chicago to Minneapolis) in multiple-system 
network 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example command: 


CTLD(MPLSS) 
The name assigned to the controller description is MPLSS. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


SWITCHED(*YES) 
Specifies that this controller is attached to a switched SDLC line. 


SWTLINLST(MPLSS) 
Specifies the name (MPLSS) of the line description (for switched lines) that this controller can be 
attached to. In the example, there is only one line (MPLSS). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system by the LCLCPNAME parameter on the CHGNETA (Change Network 
Attributes) command. 
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INLCNN(*DIAL) 
Specifies that the initial connection is made by the iSeries system either answering an incoming call or 
placing a call. 


CNNNBR(6125551111) 
The connection (telephone) number for the remote controller is 6125551111. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


TMSGRPNBR(3) 
Specifies the value (3) is to be used by the APPN support for transmission group negotiation with the 
remote system. 


The remote system must specify the same value for the transmission group. 


NODETYPE(*NETNODE) 
Specifies that the remote location (MPLS) is an APPN networking node. 


Configure network node 2 (Minneapolis) in multiple-system network 
The following CL commands are used to define the configuration for the system that is identified as MPLS 
(NN2 in|Figure 8 on page 55). The example shows these commands as used within a CL program; the 


configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[ REK KKK KKK ERK A KKK KK KKK KKK KKK KK IK KKK AKA KKK IKK AK KEK AKER AKER KK | 


/* */ 
/* MODULE: MPLS LIBRARY: PUBSCFGS */ 
/* */ 
/* LANGUAGE: CL */ 
/* */ 
/* FUNCTION: CONFIGURES APPN NETWORK: */ 
/* */ 
/* THIS IS: MPLS TO NEWYORK (switched) */ 
/* MPLS TO CHICAGO (nonswitched) */ 
/* MPLS TO CHICAGO (switched) */ 
/* MPLS TO LOSANGEL (switched) */ 
/* MPLS TO PURCH (LAN) */ 
/* MPLS TO DISTRIB (LAN) */ 
/* MPLS TO PAYROLL (LAN) */ 
/* */ 
/* */ 
[BRK RRR KK KER KK EKA KEK KEK AK KEK KKK KKK IKE KAKA IKEA KKK EKER AKER | 
PGM 


/* Change network attributes for MPLS */ 
CHGNETA LCLNETID(APPN) LCLCPNAME (MPLS) 
LCLLOCNAME (MPLS) NODETYPE(*NETNODE) 
[BRK R KKK K KEIRA KKK KK EIR K KKK KKK KKK AKA KKK AIK E AK KEK KEE A KER | 
/* MPLS TO NEWYORK (switched) */ 
[BRK RK KKK KEIRA KK ERK KKK KKK KKK KKK IK KKK KEK KKK IKKE AK KEK KKK A KER KK | 
/* Create switched line description for MPLS to NEWYORK */ 
CRTLINSDLC LIND(NEWYORK) RSRCNAME(LIN@21) CNN(*SWTPP) 
AUTOANS(*NO) STNADR(@1) COSTCNN(128) 
COSTBYTE(128) 
/* Create controller description for MPLS to NEWYORK «/ 
CRTCTLAPPC CTLD(NEWYORK) LINKTYPE(*SDLC) SWITCHED(*YES) 
SWTLINLST (NEWYORK) RMTNETID(APPN) 
RMTCPNAME (NEWYORK) INLCNN(*DIAL) 
CNNNBR(2125551234) STNADR(01) 
NODETYPE(*ENDNODE) CPSSN(*NO) 
[BRK KKK RAK KEIR KEK KKK KEK KKK KKK EKER KKK KAKA KEE AK KEK KEE KARE | 
/* MPLS TO CHICAGO (nonswitched) */ 
[BRK R KKK KK EAR REAR KEK KEK KKK KKK AK KEI KKK AK KKK EIA AK KEK EKER AKER | 
/* Create line description for MPLS to CHICAGO */ 
CRTLINSDLC LIND(CHICAGOL) RSRCNAME(LINO22) 
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/* Create controller description for MPLS to CHICAGO «/ 
CRTCTLAPPC CTLD(CHICAGOL) LINKTYPE(*SDLC) LINE(CHICAGOL) 
RMTNETID(APPN) RMTCPNAME (CHICAGO) 
STNADR(01) NODETYPE(*NETNODE) 
[RRR RK KKK ERIK KAR KKK KKK IK KKK KKK KK IK KHAKI KKK EA KER AK KEK KEKE KKK | 
/* MPLS TO CHICAGO (switched) */ 
[BERR KEK K ERIK KEIR KKK KIRKE KA KKK KK IK KIA KKK AKAIKE IKKE A KEE KARE | 
/* Create switched line description for MPLS to CHICAGO */ 
CRTLINSDLC LIND(CHICAGOS) RSRCNAME(LINO31) CNN(*SWTPP) 
AUTOANS(*NO) STNADR(01) COSTCNN(128) 
COSTBYTE (128) 
/* Create controller description for MPLS TO CHICAGO «/ 
CRTCTLAPPC CTLD(CHICAGOS) LINKTYPE(*SDLC) SWITCHED(*YES) 
SWTLINLST(CHICAGOS) RMTNETID(APPN) 
RMTCPNAME (CHICAGO) INLCNN(*ANS) 
CNNNBR(3125551111) STNADR(01) TMSGRPNBR(3) 
NODETYPE (*NETNODE) 


[RRR R KKK KK AK KKK KK KKK KKK KKK KKK KKK IK KIA KKK KKK AKIRA KER A KKK KEE KK | 
/* MPLS TO LOSANGEL (switched) */ 
[RRR K KEK KK RAK REAR KAKA KKK KKK KK AK KEK IKEA KIKI KKK KEE KARE | 
/* Create switched line description for MPLS TO LOSANGEL*/ 
CRTLINSDLC LIND(LOSANGEL) RSRCNAME(LINO32) CNN(*SWTPP) 
AUTOANS(*NO) STNADR(@1) COSTCNN(128) 
COSTBYTE(128) 
/* Create controller description for MPLS TO LOSANGEL */ 
CRTCTLAPPC CTLD(LOSANGEL) LINKTYPE(*SDLC) SWITCHED(*YES) 
SWTLINLST(LOSANGEL) RMTNETID(APPN) 
RMTCPNAME(LOSANGEL) INLCNN(*DIAL) 
CNNNBR(2135553333) STNADR(01) CPSSN(*NO) 
[RRR R KKK KK RAK KKK KKK KKK KKK KKK KK AK KIA KKK KKK IK IKEA KEI KKK K KEKE | 
/* MPLS TO LAN (LAN) */ 
[RRR RK RRA KK EAK KKK KKK KKK KKK KK KAKI KKK IKKE IKKE IKKE AKER AK KEK AKER KK | 
/* Create LAN line description for MPLS to LAN */ 
CRTLINTRN LIND(MPLSTRN) RSRCNAME (LINO11) 
ADPTADR (400000000002) 
/* Create controller description for MPLS to PURCH */ 
CRTCTLAPPC CTLD(PURCH) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME(PURCH) ADPTADR(400000000003) 
MINSWTSTS(*VRYON) SWTDSC(*NO) 
/* Create controller description for MPLS to DISTRIB */ 
CRTCTLAPPC CTLD(DISTRIB) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME (DISTRIB) ADPTADR(400000000004) 
MINSWTSTS(*VRYON) SWTDSC(*NO) 
/* Create controller description for MPLS to PAYROLL «/ 
CRTCTLAPPC CTLD(PAYROLL) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) ADPTADR(400000000005) 
RMTNETID(*NONE) RMTCPNAME (PAYROLL) 
NODETYPE (*LENNODE) 
ENDPGM 


Change the network attributes (Minneapolis) in multiple-system network 

The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for MPLS and these attributes apply to all connections in 
the network for this network node: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote locations (CHICAGO in the 
example, NN1 in the figure, LOSANGEL in the example, EN1 in figure, NEWYORK, EN1 in the figure), 
and all systems (PURCH, DISTRIB, PAYROLL) on the token-ring local area network, must specify this 
name as the remote network identifier (RMTNETID) on the CRTCTLAPPC command. 
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LCLCPNAME(MPLS) 
Specifies that the name assigned to the local control point is MPLS. The remote systems specify this 
name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(MPLS) 
The default local location name is MPLS. This name will be used for the device description that is 
created by the APPN support. 


NODETYPE(*NETNODE) 
Specifies that the local system (MPLS) is an APPN network node. 


Create the line description (Minneapolis to New York, switched) 
The line used in this example is an SDLC switched line. The command used to create the line is 


CRTLINSDLC. The parameters specified are: 


LIND(NEWYORK) 
The name assigned to the line description is NEWYORK. 


RSRCNAME(LINO21) 
Specifies that the physical communications port named LINO21 is being defined. 


CNN(*SWTPP) 
Specifies that this is a switched line connection. 


AUTOANS(*NO) 
Specifies that this system will not automatically answer an incoming call. 


STNADR(01) 
The address assigned to the local system is hex 01. 


COSTCNN(128) 
The relative cost of being connected to this line is 128; with 0 being the lowest cost and 255 the 
highest. This is used for route selection by the class of service. 


COSTBYTE(128) 
The relative cost of transferring a byte of data across this line is 128; with 0 being the lowest cost and 
255 the highest. This is used for route selection by the class of service. 


Create the controller description (Minneapolis to New York, switched) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 


controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example commana: 


CTLD(NEWYORK) 
The name assigned to the controller description is NEWYORK. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


SWITCHED(*YES) 
Specifies that this controller is attached to a switched SDLC line. 


SWTLINLST(NEWYORK) 
Specifies the name (NEWYORK) of the line descriptions (for switched lines) that this controller can be 
attached to. In the example, there is only one line (NEWYORK). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(NEWYORK) 
Specifies that the remote control-point name is NEWYORK. The name specified here must match the 
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name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (NEWYORK) by the LCLCPNAME parameter on the Change 
Network Attributes (CHGNETA) command. 


INLCNN(*DIAL) 
Specifies that the initial connection is made by the iSeries system either answering an incoming call or 
placing a call. 


CNNNBR(2125551 234) 
The connection (telephone) number for the remote controller is 2125551234. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


Create the line description A (Minneapolis to Chicago) 
The line used in this example is an SDLC nonswitched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGOL) 
The name assigned to the line description is CHICAGOL. 


RSRCNAME(LINO22) 
Specifies that the physical communications port named LINO22 is being defined. 


Create the controller description (Minneapolis to Chicago, nonswitched) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(CHICAGOL) 
The name assigned to the controller description is CHICAGOL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


LINE(CHICAGOL) 
Specifies the name (CHICAGOL) of the line description to which this controller is attached. This value 
must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
Specifies that the remote control-point name is CHICAGO. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (CHICAGO) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


NODETYPE(*NETNODE) 
Specifies that the remote location (CHICAGO) is an APPN networking node. 


Create the line description B (Minneapolis to Chicago) 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(CHICAGOS) 
The name assigned to the line description is CHICAGOS. 
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RSRCNAME(LINO31) 
Specifies that the physical communications port named LINO31 is being defined. 


CNN(*SWTPP) 
Specifies that this is a switched line connection. 


AUTOANS(*NO) 
Specifies that this system will not automatically answer an incoming call. 


STNADR(01) 
The address assigned to the local system is hex 01. 


COSTCNN(128) 
The relative cost of being connected to this line is 128; with 0 being the lowest cost and 255 the 
highest. This is used for route selection by the class of service. 


COSTBYTE(128) 
The relative cost of transferring a byte of data across this line is 128; with 0 being the lowest cost and 
255 the highest. This is used for route selection by the class of service. 


Create the controller description (Minneapolis to Chicago, switched) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(CHICAGOS) 
The name assigned to the controller description is CHICAGOS. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


SWITCHED(*YES) 
Specifies that this controller is attached to a switched SDLLC line. 


SWTLINLST(CHICAGOS) 
Specifies the name (CHICAGOS) of the line descriptions (for switched lines) that this controller can be 
attached to. In the example, there is only one line (CHICAGOS). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(CHICAGO) 
Specifies that the remote control-point name is CHICAGO. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (CHICAGO) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 


INLCNN(*ANS) 
Specifies that the initial connection is made by the iSeries system answering an incoming call. 


CNNNBR(3125551111) 
The connection (telephone) number for the remote controller is 3125551111. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


TMSGRPNBR(3) 
Specify the value (3) to be used by the APPN support for transmission group negotiation with the 
remote system. 


The remote system must specify the same value for the transmission group. 
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NODETYPE(*NETNODE) 
Specifies that the remote location (CHICAGO) is an APPN networking node. 


Create the line description (Minneapolis to Los Angeles, switched) 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(LOSANGEL) 
The name assigned to the line description is LOSANGEL. 


RSRCNAME(LINO32) 
Specifies that the physical communications port named LINO32 is being defined. 


CNN(*SWTPP) 
Specifies that this is a switched line connection. 


AUTOANS(*NO) 
Specifies that this system will not automatically answer an incoming call. 


STNADR(01) 
The address assigned to the local system is hex 01. 


COSTCNN(128) 
The relative cost of being connected to this line is 128; with 0 being the lowest cost and 255 the 
highest. This is used for route selection by the class of service. 


COSTBYTE(128) 
The relative cost of transferring a byte of data across this line is 128; with 0 being the lowest cost and 
255 the highest. This is used for route selection by the class of service. 


Create the controller description (Minneapolis to Los Angeles, switched) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example command: 


CTLD(LOSANGEL) 
The name assigned to the controller description is LOSANGEL. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


SWITCHED(*YES) 
Specifies that this controller is attached to a switched SDLC line. 


SWTLINLST(LOSANGEL) 
Specifies the name (LOSANGEL) of the line descriptions (for switched lines) that this controller can be 
attached to. In the example, there is only one line (LOSANGEL). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(LOSANGEL) 
Specifies that the remote control-point name is LOSANGEL. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (LOSANGEL) by the LCLCPNAME parameter of the Change 
Network Attributes (CHGNETA) command. 


INLCNN(*DIAL) 
Specifies that the initial connection is made by the iSeries system either answering an incoming call or 
placing a call. 
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CNNNBR(2135553333) 
The connection (telephone) number for the remote controller is 2135553333. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


CPSSN(*NO) 
Control point sessions are not supported with this node. 


Create the line description (Minneapolis to token-ring network) 
The line used in this example is a token-ring network. The command used to create the line is 
CRTLINTRN and the parameters specified are: 


LIND(MPLSTRN) 
The name assigned to the line description is MPLSTRN. 


RSRCNAME(LINO11) 
Specifies that the physical communications port named LINO11 is being defined. 


ADPTADR(400000000002) 
Specifies the LAN adapter address for the local system. 


Create the controller description (Minneapolis to Purchasing, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example commana: 


CTLD(PURCH) 
The name assigned to the controller description is PURCH. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is *LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring local area network 
line) that this controller can be attached to. In the example, there is only one line (MPLSTRN). This 
value must match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(PURCH) 
Specifies that the remote control-point name is PURCH. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (PURCH) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000003) 
Specifies the LAN adapter address of the remote controller. This must match the value specified at the 
remote controller (PURCH) in the associated line description. 


MINSWTSTS(*VRYON) 
Specifies that CP-CP sessions are established over this connection only when the status of the 
controller is varied on or active. This connection is to be treated as logically nonswitched for purposes 
of APPN routing. 
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SWTDSC(*NO) 
Specifies that the switched connection is not disconnected when the last session is unbound. This 
must be specified because MINSWTSTS(*VRYON) is specified. 


Create the controller description (Minneapolis to Distribution, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example command: 


CTLD(DISTRIB) 
The name assigned to the controller description is DISTRIB. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is “LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring network line) that 
this controller can be attached to. In the example, there is only one line (MPLSTRN). This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(DISTRIB) 
Specifies that the remote control-point name is DISTRIB. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (DISTRIB) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000004) 
Specifies the LAN adapter address of the remote controller. This must match the value that is specified 
at the remote controller (DISTRIB) in the associated line description. 


MINSWTSTS(*VRYON) 
Specifies that CP-CP sessions are established over this connection only when the status of the 
controller is varied on or active. This connection is to be treated as logically nonswitched for purposes 
of APPN routing. 


SWTDSC(*NO) 
Specifies that the switched connection is not disconnected when the last session is unbound. This 
must be specified because MINSWTSTS(*VRYON) is specified. 


Create the controller description (Minneapolis to Payroll, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example command: 


CTLD(PAYROLL) 
The name assigned to the controller description is PAYROLL. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is “LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 
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SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring local area network 
line) that this controller can be attached to. In the example, there is only one line (MPLSTRN). This 
value must match a name that is specified by the LIND parameter in a line description. 


ADPTADR(400000000005) 
Specifies the LAN adapter address of the remote controller. This must match the value that is specified 
at the remote controller (PAYROLL) in the associated line description. 


RMTNETID(*NONE) 
The PAYROLL controller is a low entry networking node and does not use a network ID. 


RMTCPNAME(PAYROLL) 
Specifies that the remote control-point name is PAYROLL. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (PAYROLL) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 


NODETYPE(*LENNODE) 
Specifies that the remote location (PAYROLL) is a low-entry networking node in an APPN network. 


Configure end node 2 (Los Angeles) 

The following CL commands are used to define the configuration for the system that is identified as 
LOSANGEL (EN2 in the figure). The example shows these commands as used within a CL program; the 
configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK RRR KKK EA KKK KKK KKK KKK KKK KEK KKK KKK EKA KEK A KKK AKKEK AKER A KERR | 


/* x/ 
/* MODULE: LOSANGEL LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL x*/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN NETWORK: */ 
/* x/ 
/* THIS IS: LOSANGEL TO MPLS (switched) x/ 
/* x/ 
/* x/ 
/* x/ 
/* x/ 
TITTLE TTT T TET LT TELE LE EEE EEE EEE REET E ELLER REEL 
PGM 


/* Change network attributes for LOSANGEL */ 
CHGNETA LCLNETID(APPN) LCLCPNAME (LOSANGEL) 
LCLLOCNAME(LOSANGEL) NODETYPE(*ENDNODE) 
[ REKR KEK KK EAR KEK KK KKK A KKK KK EAR KA KE KKKEI AIK AK KEK AKER AKER | 
/* LOSANGEL TO MPLS (switched) */ 
[BRK R KER A KK EAR KEK KER KK EKA A IKEA A KEE AK KEK KEE KKK | 
/* Create switched line description for LOSANGEL TO MPLS */ 
CRTLINSDLC LIND(MPLS) RSRCNAME(LINO41) CNN(*SWTPP) 
AUTOANS(*NO) STNADR(@1) COSTCNN(128) 
COSTBYTE (128) 
/* Create controller description for LOSANGEL TO MPLS */ 
CRTCTLAPPC CTLD(MPLS) LINKTYPE(*SDLC) SWITCHED(*YES) 
SWTLINLST (MPLS) RMTNETID(APPN) 
RMTCPNAME (MPLS) INLCNN(*DIAL) 
CNNNBR (6125553333) STNADR(01) CPSSN(*NO) 
NODETYPE (*NETNODE) 
ENDPGM 
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Change the network attributes (Los Angeles) in multiple-system network 

The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for LOSANGEL and these attributes apply to all 
connections in the network for this end node: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote locations (MPLS in the example, 
NN2 in the figure) must specify this name as the remote network identifier (RMTNETID) on the 
CRTCTLAPPC command. 


LCLCPNAME(LOSANGEL) 
Specifies that the name assigned to the local control point is LOSANGEL. The remote systems specify 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(LOSANGEL) 
The default local location name is LOSANGEL. This name will be used for the device description that 
is created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (LOSANGEL) is an APPN end node. 


Create the line description (Los Angeles to Minneapolis) 
The line used in this example is an SDLC switched line. The command used to create the line is 
CRTLINSDLC. The parameters specified are: 


LIND(MPLS) 
The name assigned to the line description is MPLS. 


RSRCNAME(LINO41) 
Specifies that the physical communications port named LINO41 is being defined. 


CNN(*SWTPP) 
Specifies that this is a switched line connection. 


AUTOANS(*NO) 
Specifies that this system will not automatically answer an incoming call. 


STNADR(01) 
The address assigned to the local system is hex 01. 


COSTCNN(128) 
The relative cost of being connected to this line is 128, with 0 being the lowest cost and 255 the 
highest. This is used for route selection by the class of service. 


COSTBYTE(128) 
The relative cost of transferring a byte of data across this line is 128, with 0 being the lowest cost and 
255 the highest. This is used for route selection by the class of service. 


Create the controller description (Los Angeles to Minneapolis) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(MPLS) 
The name assigned to the controller description is MPLS. 


LINKTYPE(*SDLC) 
Because this controller is attached through an SDLC communications line, the value specified is 
*SDLC. This value must correspond to the type of line being used as defined by a create line 
description command. 


SWITCHED(*YES) 
Specifies that this controller is attached to a switched SDLC line. 
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SWTLINLST(MPLS) 
Specifies the name (MPLS) of the line description (for switched lines) that this controller can be 
attached to. In the example, there is only one line (MPLS). This value must match a name that is 
specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system (MPLS) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


INLCNN(*DIAL) 
Specifies that the initial connection is made by the iSeries system either answering an incoming call or 
placing a call. 


CNNNBR(6125553333) 
The connection (telephone) number for the remote controller is 6125553333. 


STNADR(01) 
The address assigned to the remote controller is hex 01. 


CPSSN(*NO) 
Control point sessions are not supported with this node. 


NODETYPE(*NETNODE) 
Specifies that the remote location (MPLS) is an APPN networking node. 


Configure end node A (Purchasing) 

The following CL commands are used to define the configuration for the system identified as PURCH 
(ENA in the figure). The example shows these commands as used within a CL program; the configuration 
can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[ REKR KER A KK EAA KKK KER KKK KKK AK KEK KKK KKK AKER KKK IKKE AK KEK ERE KA KEK | 


/* */ 
/* MODULE: PURCH LIBRARY: PUBSCFGS x/ 
/* */ 
/* LANGUAGE: CL */ 
/* */ 
/* FUNCTION: CONFIGURES APPN NETWORK: x/ 
/* */ 
/* THIS IS: PURCH TO MPLS (LAN) x/ 
/* PURCH TO DISTRIB (LAN) «/ 
/* */ 
/* */ 
[KEK KKK RK KK EAA KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KAKA KKK KEK AKER KK | 
PGM 


[BRK R KKK KK EAR KERR KER KKK KKK KK KEK KKK KKK IKE KAKA KEK AKKE KEKE KARE | 

/* Change network attributes for PURCH */ 

CHGNETA LCLNETID(APPN) LCLCPNAME (PURCH) 
LCLLOCNAME(PURCH) NODETYPE(*ENDNODE) 
NETSERVER((APPN MPLS) ) 

/* Create remote configuration list for PURCH */ 

CRTICFGL TYPE(*APPNRMT) APPNRMTE( (NEWYORK APPN 

PURCH NEWYORK APPN 3BD29F *YES *NO *NO *NO 
"RMT LOC OF PURCH') 
(LOSANGEL APPN 
PURCH LOSANGEL APPN 3BD29F *YES *NO *NO *NO 
"RMT LOC OF PURCH')) 
/* Create LAN line description for PURCH to LAN x*/ 
CRTLINTRN LIND(MPLSTRN) RSRCNAME(LINO31) 
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ADPTADR (400000000003) 

/* Create controller description for PURCH to MPLS */ 

CRTCTLAPPC CTLD(MPLS) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME (MPLS) ADPTADR(400000000002) 
MINSWTSTS(*VRYON) SWTDSC(*NO) 
NODETYPE (*NETNODE) 

/* Create controller description for PURCH to DISTRIB */ 

CRTCTLAPPC CTLD(DISTRIB) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME (DISTRIB) ADPTADR(400000000004) 
MINSWTSTS(*VRYON) SWTDSC(*NO) 

ENDPGM 


Change the network attributes (Purchasing) 

The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for PURCH and these attributes apply to all connections 
in the network for this end node: 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote locations (MPLS in the example, 
NN2 in the figure) must specify this name as the remote network identifier (RMTNETID) on the 
CRTCTLAPPC command. 


LCLCPNAME(PURCH) 
Specifies that the name assigned to the local control point is PURCH. The remote systems specify this 
name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(PURCh) 
The default local location name is PURCH. This name will be used for the device description that is 
created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (PURCH) is an APPN end node. 


NETSERVER((APPN MPLS)) 
Specifies that network node MPLS (NN2 in the figure) is the network node server for this end point. 
The MPLS node is in the same (APPN) network. 


Create the remote location configuration list (Purchasing) 

The Create Configuration List (CRTCFGL) command is used to define the remote locations with special 
characteristics to the APPN support. In this example, location security is being used and the following is 
defined at PURCH: 


TYPE(*APPNRMT) 
Specifies that the entries being defined are remote locations. 


APPNRMTE((NEWYORK APPN PURCH NEWYORK APPN 3BD29F *YES *NO *NO *NO ’RMT LOC of 
PURCH’) (LOSANGEL APPN PURCH LOSANGEL APPN 3BD29F *YES *NO *NO *NO ’RMT LOC of 
PURCH’)) 

Specifies the remote locations with which the local location can be paired. Two entries are defined: 


* For the first entry: 
— The remote location name is NEWYORK 
— The remote network ID is APPN 
— The associated local location name is PURCH (defined by the default local location name); 
— The control-point name is NEWYORK and the remote control point network ID is also APPN 
— The password is 3BD29F 
— Itis a secure location 


— Itis not a single session location. The last two entries locally controlled sessions and 
pre-established sessions, are *NO because this is not a single session location. 
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¢ For the second entry: 
— The remote location name is LOSANGEL 
— The remote network ID is APPN 
— The associated local location name is PURCH (defined by the local location list) 
— The control-point name is LOSANGEL the control point network ID is also APPN 
— The password is 3BD29F 
— Itis a secure location 


— Itis not a single session location. The last two entries locally controlled sessions and 
preestablished sessions, are *NO because this is not a single session location. 


Create the line description (Purchasing to token-ring network) 
The line used in this example is a token-ring network. The command used to create the line is 
CRTLINTRN and the parameters specified are: 


LIND(MPLSTRN) 
The name assigned to the line description is MPLSTRN. 


RSRCNAME(LINO31) 
Specifies that the physical communications port named LINO31 is being defined. 


ADPTADR(400000000003) 
Specifies the LAN adapter address of the local system. 


Create the controller description (Purchasing to Minneapolis, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example commana: 


CTLD(MPLS) 
The name assigned to the controller description is MPLS. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is *LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name of the line descriptions (in this case, a token-ring network line) that this controller 
can be attached to. In the example, there is only one line (MPLSTRN). This value must match a name 
that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system (MPLS) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000002) 
Specifies the LAN adapter address of the remote controller. This must match the value that is specified 
at the remote controller (MPLS) in the associated line description. 
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MINSWTSTS(*VRYON) 
Specifies that CP-CP sessions are established over this connection only when the status of the 
controller is varied on or active. This connection is to be treated as logically nonswitched for purposes 
of APPN routing. 


SWTDSC(*NO) 
Specifies that the switched connection will not be disconnected when the last device is varied off. This 
must be specified since MINSWTSTS(*VRYON) is specified. 


NODETYPE(*NETNODE) 
Specifies that the remote location (MPLS) is an APPN networking node. 


Create the controller description (Purchasing to Distribution, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(DISTRIB) 
The name assigned to the controller description is DISTRIB. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is “LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring network line) that 
this controller can be attached to. In the example, there is only one line (MPLSTRN). This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(DISTRIB) 
Specifies that the remote control-point name is DISTRIB. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (DISTRIB) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000004) 
Specifies the LAN adapter address of the remote controller. This must match the value specified at the 
remote controller (DISTRIB) in the associated line description. 


MINSWTSTS(*VRYON) 
Specifies that CP-CP sessions are established over this connection only when the status of the 
controller is varied on or active. This connection is to be treated as logically nonswitched for purposes 
of APPN routing. 


SWTDSC(*NO) 
Specifies that the switched connection will not be disconnected when the last device is varied off. This 
must be specified since MINSWTSTS(*VRYON) is specified. 


Configure end node B (Distribution) 
The following CL commands are used to define the configuration for the system that is identified as 


DISTRIB (ENB in the figure). The example shows these commands as used within a CL program; the 
configuration can also be performed using the configuration menus. 


| Note: Read the|code disclaimer information|for important legal information. 
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[KEK KKK RKK RIKKI KKK KKK KKK KK KEK KK IK KKK KKK KKK KAKA KKK AKER AKER KK | 


/* */ 
/* MODULE: DISTRIB LIBRARY: PUBSCFGS x/ 
/* */ 
/* LANGUAGE: CL */ 
/* */ 
/* FUNCTION: CONFIGURES APPN NETWORK: x/ 
/* */ 
/* THIS IS: DISTRIB TO MPLS (LAN) x/ 
/* DISTRIB TO PURCH (LAN) x/ 
/* */ 
/* */ 
[BRK RRR KKK AK KER KKK KEK KK KEK KK IKKEKA KEK K KK I KKK A KKK KKK A KER | 
PGM 


[RRR RK KKK KEK KKK AK KKK KKK KKK KKK K EK KKK KKK KKK KKK IKEA KKK AKER AKER KK | 
/* Change network attributes for DISTRIB «/ 
CHGNETA LCLNETID(APPN) LCLCPNAME (DISTRIB) 
LCLLOCNAME (DISTRIB) NODETYPE(*ENDNODE) 
NETSERVER((APPN MPLS) ) 


[RHR K KKK KEI K KAR KKK KKK KKK KK KAKI KKK KKK KKK KAKA KKK AKER AKER KK | 


/* DISTRIB TO LAN (LAN) */ 
[BRK KKK RAK KEIR KEI KKK KKK KKK KK KEK KEIRA KEK KKK KAKA KEKE AKER | 
/* Create LAN line description for DISTRIB to LAN x/ 
CRTLINTRN LIND(MPLSTRN) RSRCNAME(LINO31) 
ADPTADR (400000000004) 
/* Create controller description for DISTRIB to MPLS «/ 
CRTCTLAPPC CTLD(MPLS) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME (MPLS) ADPTADR(400000000002) 
MINSWTSTS(*VRYON) SWTDSC(*NO) 
NODETYPE (*NETNODE) 
/* Create controller description for DISTRIB to PURCH */ 
CRTCTLAPPC CTLD(PURCH) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME(PURCH) ADPTADR(400000000003) 
MINSWTSTS(*VRYON) SWTDSC(*NO) 
ENDPGM 


Change the network attributes (Distribution) 

The Change Network Attributes (CHGNETA) command is used to set the attributes for the system within 
the network. The following attributes are defined for DISTRIB and these attributes apply to all connections 
in the network for this end node. 


LCLNETID(APPN) 
Specifies that the name of the local network is APPN. The remote locations (MPLS in the example, 
NN2 in[Figure 8 on page 55] must specify this name as the remote network identifier (RMTNETID) on 
the CRTCTLAPPC command. 


LCLCPNAME(DISTRIB) 
Specifies that the name assigned to the local control point is DISTRIB. The remote systems specify 
this name as the remote control point name (RMTCPNAME) on the CRTCTLAPPC command. 


LCLLOCNAME(DISTRIB) 
The default local location name is DISTRIB. This name will be used for the device description that is 
created by the APPN support. 


NODETYPE(*ENDNODE) 
Specifies that the local system (DISTRIB) is an APPN end node. 


NETSERVER((APPN MPLS)) 


Specifies that network node MPLS (NN2 in|Figure 8 on page 55) is the network node server for this 


end point. The MPLS node is in the same (APPN) network. 
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Create the line description (Distribution to token-ring network) 
The line used in this example is a token-ring local are network. The command used to create the line is 
CRTLINTRN and the parameters specified are: 


LIND(MPLSTRN) 
The name assigned to the line description is MPLSTRN. 


RSRCNAME(LINO31) 
Specifies that the physical communications port named LINO31 is being defined. 


ADPTADR(400000000004) 
Specifies the LAN adapter address of the local system. 


Create the controller description (Distribution to Minneapolis, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 


CTLD(MPLS) 
The name assigned to the controller description is MPLS. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is “LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring network line) that 
this controller can be attached to. In the example, there is only one line (MPLSTRN). This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system (MPLS) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000002) 
Specifies the LAN adapter address of the remote controller. This must match the value that is specified 
at the remote controller (MPLS) in the associated line description. 


MINSWTSTS(*VRYON) 
Specifies that CP-CP sessions are established over this connection only when the status of the 
controller is varied on or active. This connection is to be treated as logically nonswitched for purposes 
of APPN routing. 


SWTDSC(*NO) 
Specifies that the switched connection will not be disconnected when the last device is varied off. This 
must be specified since MINSWTSTS(*VRYON) is specified. 


NODETYPE(*NETNODE) 
Specifies that the remote location (MPLS) is an APPN networking node. 


Create the controller description (Distribution to Purchasing, token-ring network) 
Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The example 
command defines the following attributes: 
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CTLD(PURCH) 
The name assigned to the controller description is PURCH. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is *LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring network line) that 
this controller can be attached to. In the example, there is only one line (MPLSTRN). This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(PURCh) 
Specifies that the remote control-point name is PURCH. The name specified here must match the 
name that is specified at the remote system for the local control-point name. In the example, the name 
is specified at the remote system (PURCH) by the LCLCPNAME parameter of the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000003) 
Specifies the LAN adapter address of the remote controller. This must match the value that is specified 
at the remote controller (DISTRIB) in the associated line description. 


MINSWTSTS(*VRYON) 
Specifies that CP-CP sessions are established over this connection only when the status of the 
controller is varied on or active. This connection is to be treated as logically nonswitched for purposes 
of APPN routing. 


SWTDSC(*NO) 
Specifies that the switched connection will not be disconnected when the last device is varied off. This 
must be specified since MINSWTSTS(*VRYON) is specified. 


Configure low entry networking end node 1 (Payroll) 
The following CL commands are used to define the configuration for the system identified as PAYROLL 
(LENN1 in|Figure 8 on page 55). The example shows these commands as used within a CL program; the 


configuration can also be performed using the configuration menus. 


Note: Read the|code disclaimer information| for important legal information. 


[BRK R KKK KK EAR KKK KEK EKER KKEK KEIRA KEK KKK AIK EA KEKE AKER KK | 


/* x/ 
/* MODULE: PAYROLL LIBRARY: PUBSCFGS x/ 
/* x/ 
/* LANGUAGE: CL x/ 
/* x/ 
/* FUNCTION: CONFIGURES APPN NETWORK: x/ 
/* x/ 
/* THIS IS: PAYROLL TO MPLS (LAN) x/ 
/* PAYROLL TO NEWYORK (LAN) x/ 
/* PAYROLL TO LOSANGEL (LAN) x/ 
/* x/ 
OCI OO III II III II III I II II I I I I IIR IIR IR RB // 
PGM 


[BRK KKK KKK RIKKI KK ERK KKK KKK KKK KKK KAIRIE KAKA KKK AKER AKER | 
/* Create LAN line description for PAYROLL to LAN */ 
CRTLINTRN LIND(MPLSTRN) RSRCNAME(LINO11) 
ADPTADR (400000000005) 
/* Create controller description for PAYROLL to MPLS «/ 
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CRTCTLAPPC CTLD(MPLS) LINKTYPE(*LAN) SWITCHED(*YES) 
SWTLINLST(MPLSTRN) RMTNETID(APPN) 
RMTCPNAME (MPLS) ADPTADR(400000000002) 
APPN(*NO) 

/* Create device description for NEWYORK «/ 

CRTDEVAPPC DEVD(NEWYORK) LOCADR(Q0) RMTLOCNAME (NEWYORK) 
LCLLOCNAME (PAYROLL) APPN(*NO) 
CTL(MPLS) MODE(BLANK #BATCH) 

/* Create device description for LOSANGEL ~/ 

CRTDEVAPPC DEVD(LOSANGEL) LOCADR(00) RMTLOCNAME (LOSANGEL) 
LCLLOCNAME (PAYROLL) APPN(*NO) 
CTL(MPLS) MODE(BLANK #BATCH) 

/* Create device description for MPLS */ 

CRTDEVAPPC DEVD(MPLS) LOCADR(0@) RMTLOCNAME (MPLS) 
LCLLOCNAME (PAYROLL) APPN(*NO) 
CTL(MPLS) MODE(BLANK #BATCH) 

ENDPGM 


Create the line description (Payroll to token-ring network) 
The line used in this example is a token-ring network. The command used to create the line is 
CRTLINTRN and the parameters specified are: 


LIND(MPLSTRN) 
The name assigned to the line description is MPLSTRN. 


RSRCNAME(LINO11) 
Specifies that the physical communications port named LINO11 is being defined. 


ADPTADR(400000000005) 
Specifies the LAN adapter address of the local system. 


Create the controller description (Payroll to token-ring network) 

Because this is an APPN environment (iSeries system to iSeries system), the controller is an APPC 
controller and the CRTCTLAPPC command is used to define the attributes of the controller. The following 
attributes are defined by the example command: 


CTLD(MPLS) 
The name assigned to the controller description is MPLS. 


LINKTYPE(*LAN) 
Because this controller is attached through a token-ring network communications line, the value 
specified is “LAN. This value must correspond to the type of line being used as defined by a create 
line description command. 


SWITCHED(*YES) 
Always specified as *YES for token-ring network connections. 


SWTLINLST(MPLSTRN) 
Specifies the name (MPLSTRN) of the line descriptions (in this case, a token-ring network line) that 
this controller can be attached to. In the example, there is only one line (MPLSTRN). This value must 
match a name that is specified by the LIND parameter in a line description. 


RMTNETID(APPN) 
The name of the network in which the remote control point resides is APPN. 


RMTCPNAME(MPLS) 
Specifies that the remote control-point name is MPLS. The name specified here must match the name 
that is specified at the remote system for the local control-point name. In the example, the name is 
specified at the remote system (MPLS) by the LCLCPNAME parameter on the Change Network 
Attributes (CHGNETA) command. 


ADPTADR(400000000002) 
Specifies the LAN adapter address of the remote controller. This must match the value that is specified 
at the remote controller (MPLS) in the associated line description. 
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APPN(*NO) 
Specifies that this link does not use APPN networking support. All the devices must be specifically 
defined to the local system using the CRTDEVAPPC command. 


Create the APPC device (Payroll to New York) 

Because this is an APPC/APPN environment, the device is an APPC device and the CRTDEVAPPC 
command is used to define the attributes of the device. The following attributes are defined by the 
example command: 


DEVD(NEWYORK) 
Specifies that the name assigned to the device description is NEWYORK. 


LOCADR(00) 
The location address should always be specified as hex 00 when the device is associated with an 
APPC controller. 


RMTLOCNAME(NEWYORK) 
Specifies that the remote location name associated with this device description is NEWYORK. 


This value matches the value that is specified for the LCLLOCNAME parameter at the other system 
(NEWYORK). 


LCLLOCNAME(PAYROLL) 
Specifies the name that is assigned to the local location, which is PAYROLL in the example. 


This value matches the value that is specified for the RMTLOCNAME parameter at the other system 
(NEWYORK). 

APPN(*NO) 
Specifies that the networking support is not used. 


CTL(MPLS) 
Specifies that this device description is attached to a controller description that is named MPLS. 


MODE(BLANK #BATCH) 
Specifies that this device will use either of two modes: BLANK, which is a mode name of all blanks 
(hex 40), or #BATCH. Both these modes are supplied by IBM. Note that the other location must also 
use one of these modes when communicating with this location. 


Create the APPC device (Payroll to Los Angeles) 

Because this is an APPC/APPN environment, the device is an APPC device and the CRTDEVAPPC 
command is used to define the attributes of the device. The following attributes are defined by the 
example command: 


DEVD(LOSANGEL) 
Specifies that the name assigned to the device description is LOSANGEL. 


LOCADR(00) 
The location address should always be specified as hex 00 when the device is associated with an 
APPC controller. 


RMTLOCNAME(LOSANGEL) 
Specifies that the remote location name associated with this device description is LOSANGEL. 


This value matches the value that is specified for the LCLLOCNAME parameter at the other system 
(LOSANGEL). 


LCLLOCNAME(PAYROLL) 
Specifies the name that is assigned to the local location, which is PAYROLL in the example. 


This value matches the value that is specified for the RMTLOCNAME parameter at the other system 
(LOSANGEL). 
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APPN(*NO) 
Specifies that the networking support is not used. 


CTL(MPLS) 
Specifies that this device description is attached to a controller description that is named MPLS. 


MODE(BLANK #BATCH) 
Specifies that this device will use either of two modes: BLANK, which is a mode name of all blanks 
(hex 40), or #BATCH. Both these modes are supplied by IBM. Note that the other location must also 
use one of these modes when communicating with this location. 


Create the APPC device (Payroll to Minneapolis) 

Because this is an APPC/APPN environment, the device is an APPC device and the CRTDEVAPPC 
command is used to define the attributes of the device. The following attributes are defined by the 
example command: 


DEVD(MPLS) 
Specifies that the name assigned to the device description is MPLS. 


LOCADR(00) 
The location address should always be specified as hex 00 when the device is associated with an 
APPC controller. 


RMTLOCNAME(MPLS) 
Specifies that the remote location name associated with this device description is MPLS. 


This value matches the value that is specified for the LCLLOCNAME parameter at the other system 
(MPLS). 


LCLLOCNAME(PAYROLL) 
Specifies the name that is assigned to the local location, which is PAYROLL in the example. 


This value matches the value that is specified for the RMTLOCNAME parameter at the other system 
(MPLS). 


APPN(*NO) 
Specifies that the networking support is not used. 


CTL(MPLS) 
Specifies that this device description is attached to a controller description that is named MPLS. 


MODE(BLANK #BATCH) 
Specifies that this device will use either of two modes: BLANK, which is a mode name of all blanks 
(hex 40), or #BATCH. IBM supplies both these modes. Note that the other location must also use one 
of these modes when communicating with this location. 


HPR configuration examples 


See the following examples for a variety of ways to configure HPR: 
* |“Two iSeries systems as network nodes using HPR” 
¢ |“Three iSeries systems using HPR” on page 84 


Two iSeries systems as network nodes using HPR 


To configure HPR, you must first configure APPN properly. Refer to the page,}Two iSeries systems as 
network nodes using APPN 


for this configuration setup. 


Note: Systems NN1 and NN2, shown below, must have the Allow HPR transport tower support 
(ALWHPRTWR) parameter set to (*YES). 
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In Figure 9, both systems are configured as network nodes in the network attributes. This example shows 
an APPN configuration using a switched line and a nonswitched line. 


Hetwork Hode Hetwork Hode 


Honerwitched Line 


Switched Line 
Chicago Minneapolis 
RSLEs54-0 


Figure 9. HPR two-system network 


Three iSeries systems using HPR 
To configure HPR, you must first configure APPN properly. To do this refer to the page, 
systems using APPN 


Notes: 


1. Systems A and B, shown below, must have the Allow HPR transport tower support (ALWHPRTWR) 
parameter set to (*YES). These systems must be V4R2 or greater. 


2. The intermediate system must be V3R1 or greater, with the appropriate hardware. 

In Figure 10, A and B are end nodes. The network node must configure its network attributes to reflect that 
it is a network node. Each system must configure the remote control-point name in the controller 
description that represent the adjacent system. Also, A and B must indicate in the controller description for 
the network node that it can be a network node. A and B must add the network node to the server list in 
network attributes so that the network node could act as a network server for both end nodes. 


Note: Neither end node needs to configure any information about the other end node. 
End Hode WNebvrorkNode End Hode 


G 


Hew York Ghicago Los Angeles 
RSLSHo3 


Figure 10. Three-system HPR network 
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Chapter 5. Optimize APPN and HPR communication 
performance 


If you are responsible for network administration, then you may be concerned with the speed at which 
computers throughout that network can exchange data. Fortunately, you can manage the ability of a 
network to perform work and remain robust. The higher the performance, the more jobs a network can 
handle. In addition, you must consider the individual components that make up the systems in your 
network, in relation to the environment in which that system is running. If you have decided to configure an 
APPN and HPR network, review the pages: 


¢ |Performance considerations for APPN and HPR 
* |Optimizing communications using high-performance routing 


You can also take advantage of|APPN virtual controllers} as well as fine-tune |configuration parameters] to 


increase the performance of your network. 


Performance considerations for APPN and HPR 


The following can affect the performance of the APPN and HPR protocols: 
* Transmission priority 


When you create a class-of-service description, you can define one of three transmission priorities for 
each class of service. You can specify, using the transmission priority (TMSPTY) parameter, that the 
transmission priority for any class of service is high, medium, or low. 


The transmission priority you specify is carried in the session activation request at session 
establishment. The transmission priority allows each logical unit on the session and each routing entry 
along the session path to store the same transmission priority. By assigning an appropriate mode (which 
includes a class of service) at session activation time, you can ensure a better response time for the 
applications that require it. Generally, interactive traffic should have a high priority and batch traffic a low 
priority. 

* Route addition resistance 
Route addition resistance (RAR) is a relative value that indicates how desirable one network node is, as 
compared to other network nodes, for having intermediate sessions routed through it. 


Changing this value and working with the different class-of-service descriptions can control route 
sessions. 


The RAR value is defined in the network attributes for the local iSeries system. 

- Pacing values: See|Pacing (NPACING, OUTPACING, MAXINPACING) parameter|for pacing 
considerations. 

¢ Session activation considerations 


When a session is requested to a remote location that matches a network node control-point name, a 
directory search is not performed by the node that calculates the route. This is true if the session 
request is being started by a user on the network node, or on an end node that the network node is 
providing services for. Session start requests for remote locations in end nodes and remote locations in 
network nodes that do not match the control-point name of the network nodes take longer. These 
session start requests take longer because the directory search needs to be sent and the replies need 
to be received. 

¢ Maximum intermediate sessions 


The Change Network Attributes (CHGNETA) command specifies the maximum number of intermediate 
sessions that are allowed on a network node. When the number of intermediate sessions reaches 90% 
of the maximum value, the node is marked as congested. A node that is congested may or may not be 
used for intermediate sessions that depend on the class-of-service definition. The node is not congested 
when the number of intermediate sessions drops below 80% of the configured value. Also, if the 
maximum number of intermediate sessions is reached (100%), then intermediate sessions will not be 
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allowed through this network node until the value drops. You can limit the effect of intermediate 
sessions on local processing by setting an appropriate value. 
* Segmentation and reassembly 


On iSeries, some IOPs that support the local area network protocols, such as token ring and Ethernet, 
have the ability to perform segmentation and reassembly of SNA Request Units. Performing this 
function in the IOPs offloads this work from the iSeries CPU. The server CPU is free to perform other 
tasks. 


With APPN, any network congestion control is handled on a hop-by-hop basis by using |pacing| values. It 
is possible to over-drive connections in an APPN environment. A particular system could receive more 
data over a communications link than it can handle based on buffer space. The system requires the 
node that sends the data to retransmit all of the frames that were sent following the last successfully 
acknowledged frame. This retransmission occurs at the data link control (DLC) layer. 


Note: HPR does not have much IOP assist. Much of the segmentation and reassembly is done mainly 
in the iSeries CPU. 
¢ Error recovery 


APPN requires link-level error recovery to cause retransmission of lost frames. This link-level error 
recovery can only survive short and temporary outages (several seconds). If a link outage or node 
outage occurs, that is of longer duration, APPN has no recovery mechanisms for keeping the affected 
sessions active. The applications must handle any session recovery. 


The following matrix shows how HPR traffic is supported between two systems that are based on their 
HPR link-level error recovery settings. The HPR link-level error settings are exchanged between the 
systems: 


System 1 System 2 
No link-level ERP allowed |Link-level ERP required | Prefer no link-level ERP 

but could run using 
link-level ERP 

No link-level ERP allowed HPR supported (No ERP) |HPR not used HPR supported (No ERP) 

Link-level ERP required HPR not used HPR supported (uses HPR supported (uses 

ERP) ERP) 
Prefer no link-level ERP but could | HPR supported (No ERP) |HPR supported (uses HPR supported (No ERP) 
run using link-level ERP ERP) 


For information about high-performance routing, see |“Optimize communications using high-performance 


Optimize communications using high-performance routing 


High-performance routing (HPR) is the next evolution of Advanced Peer-to-Peer Networking (APPN). 
HPR is an extension of APPN and has many functional aspects common with APPN. Configuring adjacent 
stations, search processing, and route computation are the same in APPN and HPR. HPR differs from 
APPN in the areas of transport, intermediate session routing, congestion control, and error recovery. 


The following are the HPR protocol operational characteristics: 


HPR supports a key availability enhancement that is called non-disruptive path switching. This function 
provides the ability to recover from link or node outages without having session failures. This makes the 
outage transparent to the application. The application may experience a response time delay while data 
traffic is being rerouted. On iSeries, the amount of time the system takes to establish a new path, or 
re-establish the original failed route path is configurable. This error recovery feature is the key difference 
between APPN and HPR. 
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HPR can support the non-disruptive path switching feature because of an enhanced data transport 

mechanism that is called Rapid Transport Protocol (RTP). RTP is the data transport protocol that is used 

between a pair of systems that support the HPR RTP tower. This pair of systems establishes an RTP 

connection which carries out APPN sessions (multiple APPN sessions can be multiplexed over a single 

RTP connection). In order to establish an RTP connection between a pair of HPR RTP tower systems, the 

following must be true: 

* The set of nodes must support the HPR intermediate routing function. 

¢ The transmission groups (TGs) that exist between the two HPR RTP tower systems must support the 
HPR intermediate routing function. 


This routing is known as Automatic Network Routing (ANR). 


When an RTP node sends packets of data, it must keep those buffers until the RTP node receives 
acknowledgment that its RTP partner has successfully received the data. Maintaining detailed knowledge 
of data sent and received is necessary in order to provide the additional value provided by HPR, the 
non-disruptive path switching function. HPR does not rely on the data link layer to provide data 
retransmission functions. HPR supports a function that is called selective retransmission. With selective 
retransmission, only the data which has not been acknowledged gets retransmitted. For example, if an 
RTP node sends eight packets and all but the fourth packet is successfully acknowledged, then only the 
fourth would retransmit. This differs from other retransmission algorithms in which the first unsuccessful 
packet and all the subsequent packets would transmit. 


Nodes performing intermediate routing of HPR traffic or ANR, have no session awareness. HPR uses 
source routing. The nodes performing ANR simply examine packets as they receive them and determine 
the next hop of the route. The next hop is based on something that is called the ANR label. All HPR 
packets contain the ANR label. Any ANR that a network node is performing does not count as an APPN 
intermediate session. The maximum intermediate sessions parameter that is configured by means of the 
Change Network Attribute (CHGNETA) command has no effect on the ANR capacity of a system. 
Controlling the amount of ANR that different systems will perform in a network is completely dependent on 
the route selection phase of APPN session establishment. 


When sessions are carried over RTP connections, any segmentation, or reassembly is performed within 
the iSeries central processing unit (CPU). The communications IOPs do not have the information required 
to perform the segmentation and reassembly. The IOPs can not maintain the knowledge that is required by 
HPR to perform the data retransmission and non-disruptive path switching function. 


HPR uses a function called Adaptive Rated Based (ARB) congestion control. ARB regulates the flow of 
traffic by predicting congestion in the network and reducing the sending rate of a node into the network. 
ARB then attempts to prevent congestion rather than reacting to it after it has occurred. If all of the traffic 
occurring over a network was HPR, then ARB would be a fair way of sharing the bandwidth of a network. 
ARB also allows high utilization of the networking resources. When HPR traffic mixes with straight APPN 
or TCP/IP traffic, the HPR throughput may suffer because the other protocols do not practice similar 
congestion control techniques. 


For more information about configuring HPR, see|Chapter 3, “Configure APPC, APPN, and HPR” on 


APPN virtual controllers and communications performance 


An APPN virtual controller is a controller description that Advanced Peer-to-Peer Networking (APPN) can 
use, and that high-performance routing (HPR) support uses. It can be used to attach and manage 
advanced program-to-program communications (APPC) device descriptions. This type of controller does 
not represent a connection to a remote system. On iSeries, local applications that need to establish LU 6.2 
sessions to other locations in the APPN network require an APPC device description that specifies 
APPN(*YES). For simplicity, these devices are referred to as APPN devices. 
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The Allow APPN virtual support (ALWVRTAPPN) parameter is on the Change Network Attributes 
(CHGNETA) command. If the ALWVRTAPPN parameter is *YES, any existing APPN devices that are 
attached to the real APPN controller description will not be allowed to vary on. Message CPDB157 will be 
issued. If migrating to this new APPN object model, you may want to delete any existing APPN devices 
because they will no longer be used. You may also want to delete the devices if you have no intention of 
resetting the ALWVRTAPPN parameter to *NO. 


APPN virtual controllers provide the following: 
¢ Virtual controllers can reduce the number of device descriptions 


Prior to supporting APPN virtual controllers, multiple APPN device descriptions could be created and 
used simultaneously to communicate between the same local location and remote location pair. This 
situation was possible because alternate paths exist through the network. The first hop out of the local 
system (that is represented by a controller description) could be different for the two paths. After a 
session is established, the same APPN device description is used for the life of that session. With 
APPN virtual controller support, you can accomplish all communications between the same local 
location and remote location pair using a single device description. This single device description can be 
used, even if multiple paths to that remote location exist in the network. 
* Virtual controllers bypass 254 device limit 


iSeries allows a maximum of 254 devices to attach to a controller description. In some environments, 
there may be a requirement to access more than 254 different locations (that are each represented by 
devices) through a single system. For example, an iSeries may attach to a System/390, connected to 
hundreds of systems that the local iSeries would like to communicate with (through System/390). 
Without APPN virtual controller support, this communication requires the definition of parallel 
transmission groups (multiple controller descriptions) between the local system and System/390. Using 
multiple real controller descriptions can be costly in regards to both the line costs and managing 
multiple connections. With APPN virtual controller support, you use one real controller description, but 
attach more than 254 devices that are spread across more than one virtual controller. 

¢ Error recovery minimized 


APPN virtual controller descriptions do not associate with any communication lines or adjacent system. 
Thus, there are no communication failures to associate with these controller descriptions. This situation 
highlights some key points regarding error recovery: 


When APPN virtual controller descriptions are not used, device descriptions attach to APPN controller 
descriptions that represent connections to adjacent systems. When communication failures occur, 
applications that are affected by the session outages must be notified. The system also performs error 
recovery on the controller description and all of the attached device descriptions. In some large 
environments, device error recovery can take a lot of time. 


When APPN virtual controller descriptions are used, the APPN controller descriptions that represent 
connections to adjacent systems do not have device descriptions attached. When communication fails 
(for example, a line failure), the applications affected by the session outages are notified. The system 
recovers errors on the controller description. No error recovery is required on the device descriptions if 
each of the following are true: 

— The device descriptions are attached to the APPN virtual controller description. 

— The APPN virtual controller descriptions are not marked as inoperative. 


Eliminating error recovery at the device level can help decrease the amount of time iSeries requires to 
recover errors after some communication failures. 


For more information about getting optimal performance from your network, see the page 
APPN and HPR network 
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Fine-tune configuration parameters for APPC performance 


The setting of certain parameters affect the communication performance of the iSeries. To fine-tune your 
advanced program-to-program communications (APPC) performance, you can change the values for the 
following parameters: 


“Maximum length request/response unit size (MAXLENRU) parameter” 


“Maximum frame size (MAXFRAME) parameter” 


“Pacing (INPACING, OUTPACING, MAXINPACING) parameters” on page 90 


“Transmission priority (TMSPTY) parameter’ on page 90 


For more information about iSeries communications, see}Communications Configuration | 


Maximum length request/response unit size (MAXLENRU) parameter 


The maximum length of a systems network architecture (SNA) request/response unit (RU) can be 
specified with the MAXLENRU parameter in a mode description for APPC, APPN, and HPR. 


If you select a value of *CALC for the MAXLENRU parameter, the system selects an efficient size that is 
compatible with the frame size that you choose. (The frame size is on the line description command.) 
Many newer input/output processors support IOP assist. Changing the RU size to a value other than 
*CALC may negate this performance feature. 


In most situations, the use of the *CALC value for the MAXLENRU parameter gives you the optimal RU 

size. If *CALC is not used, consider the following situations when deciding on the appropriate value: 

* Choose an RU size that is slightly less than the maximum frame size or a multiple of the maximum 
frame size. This setting ensures that the largest possible frame size transmits all the time. 

* For frame relay, use RU sizes that; when combined with your packet size and protocol, minimize 
communications costs. 

* For token-ring, Ethernet, and wireless network users, use a large RU size that is slightly less than a 
multiple of the frame size. 

¢ For X.25, optimal values are from 241 through 32768. Pacing values must be coordinated when 
considering performance with the MAXLENRU parameter. 

¢ For synchronous data link control (SDLC), do not change the *CALC value on the MAXLENRU 
parameter. 


For more information about iSeries configuration, see| Communications Configuration 


Maximum frame size (MAXFRAME) parameter 


The maximum frame size is specified in the MAXFRAME parameter in the line and controller descriptions. 
Larger frame sizes generally supply better performance. Large frame sizes may not work well for 
error-prone lines or networks because longer times are required to transmit large frames when errors are 
encountered. 


For each line type, set these maximum frame sizes in the line description. 


To take advantage of these large frame sizes, these values must be configured correctly. The MAXFRAME 
parameter on the line description and controller description must reflect the maximum value. 


Note: For X.25, increase the DFTPKTSIZE parameter value and MAXFRAME parameter value to its 
maximum value. 


Having configured a large frame size does not negatively affect performance for small transfers. Note that 


both the server and the other link station must be configured for large frames. Otherwise, the smaller of 
the two maximum frame size values are used in transferring data. Bridges may also limit the frame size. 
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Note: In order to run HPR, MAXFRAME must be set to at least 768. 


For more information about iSeries communications, see [Communications Configuration 
Pacing (INPACING, OUTPACING, MAXINPACING) parameters 


Pacing is required if there is a possibility of overflowing data buffers internal to the controller or the host 
system. This usually occurs if the controller or host must pass the data to a device that operates at a slow 
speed. If the host system receives a pacing response, it sends more data frames up to the window size to 
the controller. 

* Pacing determines how many message units (SNA RUs) can be transferred over a session before 
receiving an acknowledgment from the receiving system. An excessive number of pacing responses 
may adversely affect network performance. However, the absence of pacing could cause network 
congestion and unfair utilization of iSeries resources (buffers and central processing units). The values 
that you can use in negotiating the pacing values with the adjacent system are determined from the 
INPACING and OUTPACING values on the mode description. The iSeries will not allow these values to 
be negotiated to a higher value. If necessary, the receive pacing value negotiate to a lower value, 
matching the INPACING value. 

* The pacing value is determined at session establishment time and is not changed for the duration of the 
session for the following reasons: 

— The adjacent system does not support adaptive pacing 
— The transmission priority is low priority 

* If the adjacent system does support adaptive pacing, the minimum pacing value is set at session 
establishment time using the INPACING and OUTPACING values. The location that starts the session 
establishment (BIND request) is responsible for setting the values. No negotiation of the values is 
performed. However, support is provided by the system to change or adapt the pacing values based on 
the system’s buffer resources and traffic patterns in the network. The system can now allocate its 
session buffers automatically to efficiently use its available resources. The MAXINPACING parameter 
defines the upper limit on the number of session buffers. The default value of *CALC sets an upper limit 
of 2 for the INPACING value. 

¢ The iSeries system also has the ability to slow down the transfer of data or even stop receiving at any 
node of any session. This allows for more equity in the network by dynamically turning the flow of 
messages on to any hop for any session that may be contributing to congestion problems. In general, 
the value of the INPACING, OUTPACING, and MAXINPACING parameters on the mode description can 
affect the data rate, network congestion, buffer utilization, and central processing unit (CPU) utilization. 


Transmission priority (TMSPTY) parameter 


The transmission priority (TMSPTY) parameter is on the class-of-service (COS) description. When you 
create a class-of-service description, you can define one of three transmission priorities for each class of 
service. You can specify, by the transmission priority (TMSPTY) parameter, that the transmission priority 
for any class of service is high, medium, or low. 


The session activation request carries the transmission priority you specify when a session is established. 
This allows each logical unit on the session and each routing entry along the session path to store the 
same transmission priority. You can ensure better response time for the applications that require it by 
assigning an appropriate mode (which includes a class of service) at session activation time. 


Note: Generally, interactive traffic should have a high priority and batch traffic a low priority. 
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Chapter 6. APPC, APPN, and HPR security considerations 


The following are some aspects of security for iSeries systems communicating with each other using 
APPC, APPN, and HPR: 
¢ General security considerations: 


Consider the following measures when securing your network: 


Note: The following password considerations only apply if password protection is not active. 

— When application program security is used, specify SECURELOC(*VFYENCPWD). This means that 
you only get to log on if BOTH your user profile name AND password are the same on both systems 

— The person responsible for network security ensures that each user has a unique user ID throughout 
the network. 

— Have your system administrator set a limit on the number of consecutive password attempts that are 
not valid for a given display device. When this limit is reached, the device is then varied off. Set the 
limit with the system value QMAXSIGN. 


Note: This is only true for Display devices, not for APPC devices. 
— Users can sign on to more than one iSeries system with the same profile. To limit the user profile to 
one sign-on: 
- Set the system value (*“SYSVAL) for LMTDEVSSN parameter on either the Create User Profile 
(CRTUSRPRF) or Change User Profile (CHGUSRPRF) command. 
Physical security considerations: 


You are responsible for the physical security of your system when you specify *NONE for the location 
password (LOCPWD) parameter during APPC configuration. In this case, the iSeries system does not 
validate the identity of a remote system when a session is being established. However, you can still use 
application-level security if the remote system supports it. For example, if the remote system is an 


iSeries system with security level 20 or above. 
* |Session-level security| 


Only security for communications or multiple systems management is discussed on this page. Security 
needs to be consistent across all the systems in a network if intersystem access is to be controlled and 
yet not unnecessarily restricted. 


For security considerations specific to running APPN and HPR over your network, refer to|Protecting your 
system in an APPN and HPR environment for more information. 
For a more complete discussion of security considerations, see the|Tips and Tools for Securing your 


Serie book. 


Session-level security for APPN and HPR 


Session-level security is achieved by specifying a password on the LOCPWD parameter during 
configuration. The iSeries system uses the password to validate the identity of the remote system during 
session establishment. The password must match the password specified on the remote system, or the 
connection is not allowed. 


If the remote system does not support session level security (Series/1 RPS version 7.1, CICS/VS release 
1.6): 
* Specify LOCPWD(*NONE) to establish the connection, and provide the necessary physical security 


There is a security concern when you create device descriptions with APPN(*YES), and when APPN 
automatically creates and varies on a device description with the same remote network ID, location name, 
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and local location name as the APPN remote location configuration list entry. To compensate for remote 
locations using an independent device description with APPN(*YES): 
¢ Add an entry to the APPN remote location configuration list that includes security information 


Note: In order to avoid using security information that cannot be predicted, ensure that all the device 
descriptions, as described above, contain exactly the same security information. 


Protect your system in an APPN and HPR environment 


APPN networks provide open connectivity, and require minimal configuration by each system in the 
network. When a system has a connection into an APPN network, it can establish sessions with other 
systems that are connected within that APPN network. 


APPN reduces the physical, configuration barriers to communications. However, you might want to build 
some logical barriers between systems in the network for security reasons. This ability to control which 
systems can connect to yours is often called firewall support. Network administrators might use a variety 
of node types to specify which connections between APPC locations are allowed. For example, you might 
want to allow SYSTEMB to communicate with SYSTEMA and SYSTEMD, but not with SYSTEMC. The 
page, |APPN filtering support] gives an explanation of this. For an example see [creating a session endpoint 
To expand on this, administrators can ssaldacs of cence (COS) ound select nodes and 
transmission groups that are eligible for inclusion in network session routes. 


APPN filtering support 


Before we discuss APPN filtering support, an explanation of node types in an APPN network is needed: 

¢ A peripheral node is at the edge of a network. It can participate in the network, but it cannot provide 
intermediate routing to other systems in the network. A peripheral node can be an end node (EN) such 
as MADISON and PARIS in the figure below. A peripheral node can be a low-entry networking node 
(LEN), such as CHICPC1 and CHICPC2. A peripheral node can also be a network node in a different 
network (NETID). From CHICAGO’s perspective, LONDON is a peripheral node. 

* A network node (NN) provides routing services among systems in the network. In CHICAGO, and 
ATLANTA are examples of network nodes. 

¢ A Branch Extender node is an extension to the APPN network architecture that appears as a network 
node (NN) to the Local Area Network (LAN), and as an end node (EN) to the Wide Area Network 
(WAN). This reduces topology flows about resources in the LAN from being disconnected from the 
WAN. 


APPN filtering support provides the ability to create a firewall that is based on APPC location names. You 

use two different types of filter lists: 

¢ A session-endpoint filter controls access to and from a location. For example, in the session endpoint 
filter on the CHICAGO system in the figure below, it specifies which locations can establish a session 
with CHICAGO or with PAYROLL. CHICAGO and PAYROLL are two different locations on the 
CHICAGO system. 


Similarly, the session endpoint filter on the MADISON system specifies which locations can establish a 
session with the MADISON location. 
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Figure 11. Two connected APPN networks 
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On iSeries, you can use the new QAPPNSSN configuration list, by itself or in conjunction with the 
QAPPNRMT configuration list, to create a session endpoint filter. 

¢ Adirectory search filter on a network node determines the following for its associated peripheral 
nodes: 

— Access from the peripheral node (when the peripheral node is the requester). For example, in you 
can use the directory search filter on LONDON to control the possible destinations for users on the 
PARIS system. Similarly, you can use the directory search filter on CHICAGO to control the possible 
destinations for users on CHICPC1 and CHICPC2. 

— Access to the peripheral node (when the peripheral node is the destination). In for example, you can 
use the directory search filter on CHICAGO to determine which locations can access CHICPC1. 
Because both CHICAGO and DALLAS provide connections to MADISON, you must set up the 
directory search filters on both CHICAGO and DALLAS to restrict connections to MADISON. 


Similarly, you can use the directory search filter on CHICAGO to specify which USANET locations 
are permissible destinations for EJRONET users. 


To create a directory search filter use the QAPPNDIR configuration list. 


Create a session endpoint filter 


The following are two different methods for creating a session endpoint filter on the CHICAGO system in 
the figure below. They must satisfy the following requirements: 

¢ Only the FINANCE location can establish a session with the PAYROLL location. 

* The CHICAGO location can communicate with any USANET location except PAYROLL. 

* The CHICAGO location can communicate with LONDON. 
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Figure 12. Two connected APPN networks 
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* Using the QAPPNSSN and QAPPNRIT configuration lists together: 


The most secure method for creating a session endpoint filter is to use the QAPPNSSN configuration 
list and the QAPPNRMT configuration list together. The QAPPNRMT configuration list provides 
password security between systems, which helps to protect from an imposter system (a system or user 
that is pretending to be another system). 
When you use this method, you create the QAPPNSSN configuration list that does not specify any 
remote locations. It points to the QAPPNRMT configuration list. 
The drawback to this method is that you must explicitly define each location pair on the QAPPNRMT 
configuration list. If you want the CHICAGO location (which is on the same system as the PAYROLL 
location) to communicate with other locations, you need to add an entry for each pair. 

¢ Using the QAPPNSSN configuration list by itself: 
When you specify remote locations in the QAPPNSSN configuration list, your configuration task is 


simpler because you can use generic names and wildcard entries. However, when you use this method, 


you do not have the protection of password verification between locations. In addition, when you use 
generic names and wildcards, the system might accept or reject requests in a different way than you 
intended. 


Class of service (COS) routing 


Network nodes maintain information about all network nodes and links between network nodes. When a 
session is requested, a mode is specified. Each node contains a class of service (COS) parameter that 
specifies the class of service description that will be used to calculate the route the session will take. The 
class of service also specifies the transmission priority that will govern the rate of data transfer after the 
session has been established. 


The following class-of-service descriptions are shipped with the iSeries system: 
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* #CONNECT: the default class of service 

¢ #BATCH: a class of service that is tailored for batch communications 

* #BATCHSC: is the same as #BATCH except that a data link security level of at least *PKTSWTNWK is 
required 

¢ #INTER: a class of service that is tailored for interactive communications 

¢ #INTERSC: is the same as #INTER except that a data link security level of at least “*PKTSWTNWK is 
required 


If you need to force a particular route to be selected, a user class of service (COSD) can be created. See 
Creating a class-of-service description|for a thorough explanation. 
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Chapter 7. Troubleshooting APPN and HPR 
If an error log indicates that the route to the remote location cannot be found, the [Start Pass-Through] 


command attempts to make the connection again. The STRPASTHR command has built-in 
detailed diagnostic capabilities that exceed those provided by other interfaces that use APPN, or HPR 
networks. These diagnostic capabilities include problem analysis, functions for problem and error logging 
(including directory services search information), and route calculation information. However, the system 
records all session initiation errors in the error log. 


When a STRPASTHR command fails to contact a remote location in an APPN network, a record is written 
to the problem log. The record is written if there is an associated problem record for analyzing the data. 
The Work with Problems (WRKPRB) and Analyze Problem (ANZPRB) commands enable you to examine 
and interpret the problem log to help you isolate the problem. 


The command can help you understand the topology of your 
network. It displays the names of all known remote control points and their locations, intermediate 
sessions, and link status information. The [Work with APPN Status (WAKAPPNSTS)| command provides 
session-related information for advanced program-to-program communications (APPC) controller 


descriptions. These controller descriptions represent connections to adjacent systems by using Advanced 
Peer-to-Peer Networking (APPN), or high-performance routing (HPR). 


If no problem record exists for a particular type of error, the system does not record a message in the 
problem log. However, the system records all errors in the error log. The error log entry may help your 
service personnel isolate the problem. 


If you have a communication problem specifically related to APPN and HPR running over your system, 
reviewing the following pages may also help in troubleshooting: 


¢ |Solve communication problems using session activity’ 


¢ |Finding System Network Architecture sense codes 
¢ |APPN error log data 


Solve remote communication problems using STRPASTHR 


When you encounter problems indicating the route to the remote location cannot be found, you can 
attempt to make the connection again. Use the Start Pass-Through (STRPASTHR) command to assist in 
troubleshooting. The STRPASTHR command has built in diagnostic capabilities that exceed those that are 
provided by other interfaces that utilize APPN networks. These diagnostic capabilities include problem 
analysis, problem logging, and error logging functions. 


When a STRPASTHR command fails to contact a remote location in an APPN network, a record is written 
to the problem log. This occurs only if there is an associated problem analysis for analyzing the data. The 
Work with Problems (WRKPRB) and Analyze Problem (ANZPRB) commands enable you to examine and 
interpret the log to help you isolate the problem. 


When a start pass-through attempt has failed, an error log is issued. You can use these error logs to assist 
in troubleshooting your communication problem. See|APPN error log data} for more information. 


Solve communication problems using DSPAPPNINF 


Isolating a routing problem in an Advanced Peer-to-Peer Networking (APPN) network can be challenging. 
You can view the APPN information to assist you in understanding the topology of network nodes and 
some of their locations. 
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To display APPN Information, type the command DSPAPPNINF on a command line and press F4. You can 
also select option 6 (Display APPN information) on the Network Management menu. 


The information the system displays, prints, or stores depends on the options you select. The system 
displays additional options that are based on previous options that are selected. 


See the following scenario for help in using the DSPAPPNINF command: 
* Type DSPAPPNINF *TOPOLOGY on System A. 
— Type 5 next to System A to display the Display Link Destination Nodes display. 


The Display Link Destination Nodes display identifies how this node’s topology database looks. The 
link Active Column identifies whether APPN will consider the link in route computation. If a link Active 
column value is No, this indicates the link will not be included in APPN route selection. 

— Next type a 5 to Display Link Characteristics. This information along with the information from the 
Display Network Attributes (DSPNETA) command identifies the transmission group (TG) values and 
node values. 


With this information, you can determine why a path is taken or why one is not being taken for the 
class of service (COS). 
* If you type, DSPAPPNINF *LCLNODE on System A, 


This allows you to determine what locations are known by the local node. It shows locations that are 
configured on the local node and locations that are found by previous searches. 
¢ If you type, DSPAPPNINF *SSN on System A, 


This allows you to look at up to 200 endpoint sessions that were successfully established since the last 
IPL. You can also see the route that was taken by that session, error data, session start BIND, end 
time, pacing that is used, and others. 

¢ If you type, DSPAPPNINF *SSN SSNTYPE(*INMSSN) on System A, 


This allows you to determine whether active sessions are routed through the local system. You may, for 
example, want to vary off a controller, but need to know whether it is being used for intermediate 
sessions. You can also see which controller descriptions are associated with an intermediate sessions. 


Solve communication problems using WRKAPPNSTS 


The Work with APPN Status (WRKAPPNSTS) command provides session-related information for 
advanced program-to-program communications (APPC) controller descriptions running Advanced 
Peer-to-Peer Networking (APPN), or high-performance routing (HPR). The controller descriptions represent 
connections to adjacent systems. You use the WRKAPPNSTS command to provide the following 
information about APPN controller descriptions: 

* The system shows all the location pairs that have one or more sessions over the controller description. 
The session activity is not limited to those sessions in which the local system is the source, or target of 
the session. Information about APPN intermediate sessions and cases when the local system is 
performing the APPN, or HPR boundary function, are also provided. 


Note: Automatic Network Routing (ANR) traffic is not shown. 

* You can display session information for the location pairs that are associated with a controller. The 
session information provides a tie between a particular session and the device description the system 
uses. For example, a device description attached to the real controller description is shown, or an APPN 
virtual controller description is shown. 

¢ You can display information about Rapid Transport Protocol (RTP) connections that either originate, or 
end on the local system. It is also possible to see the location pairs and session information associated 
with the sessions that are carried over the RTP connection. 

¢ You can display the route that a particular RTP connection has taken through an HPR subnet. 

* You can request the system perform some operations against these RTP connections. These operations 
include requesting the system to perform a non-disruptive path switch, and ending an RTP connection 
that is currently active. You can issue both of these operations against one of the following: 

— Asingle RTP connection 
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— All of the RTP connections that have the first hop of their route across the controller description 
being displayed 


Solve communication problems using session activity 


Viewing session activity, or actual work that occurs between the local system and adjacent systems allows 
you to view network attributes, mode, class-of-service (COS), and topology information. You might want to 
see information about the session activity for any of the following reasons: 

* Activity occurs over the controller descriptions to adjacent systems 

e When certain sessions are established over a connection that the operator did not expect 

* The optimal route is no longer operating: 


To find another route for the session, you may need to know what location pairs are using for a 

particular connection. If you have to change the route for any session, you might need to vary off the 

controller description. Before varying off controller descriptions, you can do the following: 

— Determine whether any active sessions are using that connection (so you can notify the affected 
users of the upcoming outage) 

— Delay the varying off of the controller description 


For more information about session activity, see|“Solve communication problems using WRKAPPNSTS?” on 


Finding Systems Network Architecture sense codes 


Systems Network Architecture (SNA) sense codes contain additional information for the system 
programmer, and system support personnel about the error, or problem that has occurred on the network. 


APPN error log data 


This page defines the APPN session setup data that is supplied when an error log is issued for a start 
pass-through failure. This failure results in message CPF8933 (Route to specified location not found) being 
issued to the user’s work station. The following information should be used for error log entries with the 
reference codes 7100 and 7101. 


Note: Use the Work with Problems (WRKPRB) command for error log entries with the reference code 
7102. 


For a detailed description of APPN error log data, review the following pages: 


Standard APPN diagnostic data 
APPN session setup states 


Standard APPN diagnostic data 


The table below defines the format of APPN error log entries. The information available in the error log 
depends on how far the session initiation attempt had proceeded when the failure or time-out occurred. 


Table 3. APPN Error Log Data 


Byte Bit Content 
Session Setup Control Information 
0-3 Length of entire APPN error log structure 
4-15 Reserved 
16-17 Reserved 
18-19 Time out session setup state (available if session failed due to time-out) 
1A-21 Reserved 
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Table 3. APPN Error Log Data (continued) 


Byte Bit Content 
22 Flag bits 
0 Local system node type (0 = end node and 1 = network node) 
1 Session setup request should no longer be tracked 
2 A final session state has been reached 
3-7 Reserved 
Pre-search Phase Data 
23 Pre-search phase data measurements 
0 Pre-search phase data is valid to look at because some of the fields have been 
filled in 
1-7 Reserved 
24-2B Local location name 
2C-33 Remote location name 
34-3B Remote network identifier 
3C-43 Mode name 
44-4D Device description name 
4E-57 Controller description name 
58-71 PCID (procedure correlation identifier) 
72-79 Class-of-service name 
Common Information During Search Phase 
7A Common information during search phase 
0 Common information data is valid to look at because some of the fields have 
been filled in 
1 Wildcard entry was used to satisfy search 
2-7 Reserved 
7B-82 Network identifier for the destination node 
83-8A Control-point name for the destination node 
8B-92 Network identifier for the network node server of the destination node 
93-9A Control-point name for the network node server of the destination node 
9B-9E Reserved 
9F-A6 The network identifier of the remote location that was found using the *ANY 
directory entry 
A7-AE The control-point name of the remote location that was found using the *~ANY 
directory entry 
AF-B6 The network identifier of the network node server of the remote location that was 
found using the *ANY directory entry 
B7-BE The control-point name of the network node server of the remote location that 
was found using the *ANY directory entry 
Directory Search Summary Information - End Node 
BF Directory search summary information - end node 
0 End node search information is valid to look at because some of the fields have 
been filled in 
1 Search type (0 = local only search and 1 = distributed search) 
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Table 3. APPN Error Log Data (continued) 


Byte Bit Content 
2 Real indicator supplied by the network node server 
3 Default indicator supplied by the network node server - note that the real and 
default server-supplied indicators are mutually exclusive 
4-7 Reserved 
C0-C7 Network identifier of the network node server for the local system 
C8-CF Control-point name of the network node server for the local system 
Directory Search Summary Information - Network Node 
DO Network node directory steps processed indicators 
Network node search information is valid to look at because some of the fields 
have been filled in 
1 Query topology database for a network node control-point name 
2 Location found in local directory database 
3 One hop search sent to an attached end node 
4 Route selection attempted for a directed search to a network node 
5 Directed search sent to network node 
6 Reserved 
7 Reserved 
D1 0 Domain broadcast sent 
1 Broadcast search sent 
2 Reserved 
3 Reserved 
4-7 Reserved 
D2-D9 Directed search target network identifier 
DA-E1 Directed search target control-point name 
E2-E9 Reserved 
EA-F1 Reserved 
F2-F9 Reserved 
FA-101 Reserved 
Switched Link Activation 
102 0 Link activation data is valid to look at because some of the fields have been filled 
in 
1-7 Reserved 
103-10A First hop of the route network identifier (real node) 
10B-112 First hop of the route control-point name (real node) 
113-11A First hop of the route network identifier (virtual node) 
11B-122 First hop of the route control-point name (virtual node) 
123 Transmission group number for first hop of route 
124-12D Line description name 
12E-131 Reserved 
132-133 Reason code for error 


Generic Session Setup Information 
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Table 3. APPN Error Log Data (continued) 


Byte Bit Content 

134-137 Sense code returned 

138-15D Past session setup states 

15E-15F Current session setup state 

160-17F Reserved 

180 Variable data area (see[‘Optional APPN diagnostic data” on page 106) 


Note: O=false and 1=true on the bit fields, unless otherwise specified. 


APPN session setup states 


The following table presents the possible session setup states for APPN while it processes a session 
initiation request. One of these values always resides in the current session setup state. 


Table 4. APPN Session Setup States 


Siate Reason 

1000 Session setup complete. An existing session will be used; therefore, APPN control point functions will 
not be called. 

1015 Session setup request has failed. Refer to sense code for details. 

1020 Session setup rejected. The local location name chosen is not defined in either the network attributes or 
as a local location list entry. 

1025 Session setup rejected. Mode name specified is not defined on the system. 

1030 Session setup request has been sent by location manager to resource manager to obtain a device. 

1032 Session setup request cannot be satisfied with a non-APPN device or with an existing APPN session. 
The APPN control point has been called to establish a new session. 

1035 Session setup has been pended because of a previous request that is waiting for the request 
transmission group vectors processing to complete. 

1040 Session setup has been pended because of a previous request that is still waiting for the route selection 
phase (request single hop route - end node) to complete. 

1050 Session setup has been pended because of a previous request that is still waiting for the route selection 
phase (request route - network node) to complete. 

1060 Session setup has been pended because of a previous request that is still waiting for the switched link 
activation phase to complete. 

1070 Session setup has been pended because of a previous request that is still waiting for the location 
search phase to complete. 

1080 A request transmission group vectors request is outstanding to topology routing services component. 

1082 A request transmission group vectors request is being processed by topology routing services 
component. 

1084 The request transmission group vectors response was returned by the topology routing services 
component. 

1086 The request transmission group vectors request has been received by session services. 

1090 Location search phase request is outstanding, but has not yet been received by the local system’s 
directory services function. 

End Node Location Search Phase (2000 - 2999) States 

2000 The local system's directory services has received the search request and has begun its processing. 

2010 There is a one hop search request outstanding to the local system’s network node server. 

2020 Location search processing has been completed by the local system’s directory services. 
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Table 4. APPN Session Setup States (continued) 


State Reason 

2025 Session services has received the locate message response from directory services. 

2030 Location search phase has failed. The owning control point for the remote location could not be 
determined during the search phase. In this case, the search was forwarded to our network node server 
and the location could not be found. 

2040 Location search phase has failed. The owning control point for the remote location could not be 
determined during the search phase. In this case, the search was not sent out of the local system 
because of no network node server, and there was no network node that the local system could simply 
forward the bind to. 

2050 Location search phase has failed. The network node server has sent an SNA negative response 
indicating that the route selection control vector (RSCV) required is larger than 255 bytes. 

2060 Location search phase has failed. The network node server has sent an SNA negative response 
indicating that the class-of-service is not valid. 

2070 Location search phase has failed. The network node server has sent an SNA negative response 
indicating a route-not-available condition. 

Network Node Location Search Phase (3000 - 3999) States 

3000 The local system’s directory services has received the search request and has begun its processing. 

3010 Query control-point name outstanding. A request to determine if the remote location is the name of a 
network node control point in the topology database is outstanding. 

3012 Query control-point name request is being processed by topology routing services. 

3014 Query control-point name response has been sent by topology routing services. 

3016 Query control-point name response has been received by directory services. 

3020 One hop search request is outstanding to an attached end node. 

3030 A request for a route is outstanding to topology routing services so that a directed search can be sent to 
another network node. 

3032 Request route for directed search is being processed by topology routing services. 

3034 Request route response for directed search has been sent by topology routing services. 

3036 Request route response for directed search received by directory services. 

3040 A directed search request is outstanding to another network node. 

3050 A request for a route is outstanding to topology routing services for a remote search. 

3052 Request route for a remote search is being processed by topology routing services. 

3054 Request route response for a remote search has been sent by topology routing services. 

3056 Request route response for a remote search was received by directory services. 

3060 A routed search request is outstanding to a network node. 

3070 A domain broadcast is currently being run. This involves querying attached end nodes or network nodes 
in another network to determine if the location is known by that system. 

3080 A broadcast search is outstanding to one or more directly attached network nodes (this could involve 
attached network nodes that have access to multiple networks). 

3090 A request for a route is outstanding to topology routing services to determine if a node that can access 
multiple networks exists so that it can determine where the remote location exists. 

3092 Request route for a node that can access multiple networks is being processed by topology routing 
services. 

3094 Request route response for a node that can access multiple networks has been sent by topology routing 
services. 

3096 Request route response for a node that can access multiple networks was received by directory 


services. 
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Table 4. APPN Session Setup States (continued) 


Siate Reason 

3100 A search request is outstanding to a node that can access multiple networks. 

3110 A request is outstanding to the session services component in order to perform functions necessary to 
send searches into a different APPN network. 

3120 The location search phase has completed and a response has been returned by directory services. 

3125 The location search phase has completed and the response has been received by session services. 

3130 The location search phase has failed. 

Route Selection Phase (4000 - 4999) States 

4000 A request for a single hop route is outstanding to the topology routing services component. 

4002 The request for a single hop route is being processed by topology routing services. 

4004 The request single hop route response has been returned by topology routing services. 

4006 The request single hop route response has been received by session services. 

4010 A request single hop route failure has occurred. 

4030 A request for a route is outstanding to the topology routing services component. 

4032 The request for a route is being processed by topology routing services. 

4034 The request route response has been returned by topology routing services. 

4036 The request route response has been received by session services. 

4040 The request for a route has failed. The class-of-service name being used is not defined on the local 
system. 

4050 The request for a route has failed. The route selection control vector required to satisfy the end-to-end 
route is larger than the architected limit (255 bytes). 

4060 The request for a route has failed. Route-not-available condition has been detected. No destination 
network nodes or virtual nodes are available for intermediate routing. 

4062 The request for a route has failed. Route-not-available condition has been detected. A route that 
satisfies the user class-of-service but which uses inactive transmission groups does exist. 

4064 The request for a route has failed. Route-not-available condition has been detected. A route that has 
active transmission groups but which does not meet the class-of-service requirements does exist. 

4066 The request for a route has failed. Route-not-available condition has been detected. A route that has 
active transmission groups but which does not meet the class-of-service requirements does exist. A 
route that satisfies the user class-of-service but which uses inactive transmission groups also exists. 

4068 The request for a route has failed. Route-not-available condition has been detected. Destination 
intermediate routing nodes exist, but no route of any type can be calculated. 

4080 Session setup failure. The controller description that represents the first hop of the route is unknown by 
the local system. 

Switched Link Activation Phase (5000 - 5199) States 

5000 The request to activate the switched link is currently outstanding from session services. 

5005 Configuration services has begun processing the activate route request but has not yet completed its 
processing. 

5010 The activate route has completed, but some failure has occurred. Details are based on sense code. 

5020 The request to activate the switched link has been pended. A controller description is being created or 
varied on for establishing a link using the connection network. 

5030 The request to activate the switched link has been pended. The controller is not allowed to make a 
connection in this state. The probable cause is a message outstanding for this controller description. 

5040 The request to activate the switched link has been pended. Configuration services is waiting for the 
operating system to issue the command to activate the switched connection. 
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Table 4. APPN Session Setup States (continued) 


State Reason 


5050 The request to activate the switched link has been pended. The attempt to select an eligible line 
description for this request has failed. The probable cause is a message that is outstanding requiring 
operator intervention. 


5070 The request to activate the switched link has been pended. The system is currently in the process of 
establishing an outgoing connection. 

5080 The request to activate the switched link has been pended. The outgoing connection has been made, 
but the exchange identification phase is in progress. 

5090 The request to activate the switched link has been pended. The outgoing connection or exchange 
identification phase has failed. The system is waiting for the operator to respond to a message. 

5100 The switched link activation has completed successfully. 

5110 The session services component has received its response to its switched link activation request. 

Non-Switched Link Activation Phase (5200 - 5299) States 
5200 Session services is waiting for configuration services to complete the non-switched link activation. 
5210 The non-switched link activation phase has completed successfully. 
HPR Route Setup Phase (5300 - 5399) States 

5300 A request to determine whether a session should be carried over an RTP connection is outstanding. 

5310 The request to determine if an RTP connection should be used for the session has detected an error. 

5315 An HPR Route Setup request is outstanding. 

5320 The HPR Route Setup request was returned with a good completion. 

5325 The HPR Route Setup request has failed. 

5330 The HPR Route Setup phase has completed successfully. 

APPN Virtual Controller Selection Phase (5400 - 5499) States 

5400 The request is outstanding to the virtual controller manager component to find the APPN virtual 
controller description. 

5490 The request to find the APPN virtual controller description has failed. 

5495 The request to find the APPN virtual controller description has completed successfully. 

Device Selection Phase (6000 - 6999) 

6000 A request is outstanding to the T2 station input/output manager (IOM) task to select a device. 

6005 The T2 station input/output manager (IOM) task has begun processing the get device request. 

6010 Device selection pended. The device was found, but it is in the process of being automatically varied 
on. 

6020 Device selection pended. No device was found; therefore, a new device is in the process of being 
created and varied on. 

6025 Device selection request pended. A dynamic device creation or vary on is already in progress for a 
previous get device request or for a received bind request. 

6030 The device selection has failed. Refer to the sense data returned for an explanation of this failure. 

6040 The device selection phase was completed successfully by the T2 station input/output manager (IOM) 
task. 

6045 The device selection response was received by session manager. 

6050 APPN session manager processing is complete. 

6060 The session setup has completed successfully. 
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Optional APPN diagnostic data 


The optional APPN diagnostic data is presented in a format similar to the format of a control vector. This 
data is located after the standard APPN diagnostic data. More than one type of variable data can be 
present. The type of optional data that is contained in the error log depends on the current session setup 
state at the time the error or time-out occurred. This data begins at offset X'0312' from the start of the 
error log entry. 


Header information exists at the beginning of each variable data element. This provides the length and key 
value of the data area element (similar to the way that control vectors are structured). 


Search-Sent Elements 

This structure defines a search-sent information element. Multiple elements may be supplied. The header 
information length is used to determine the length of a single element. At times, only specific search types 
and search results are supplied. These are performed for the session setup state domain broadcast (3070) 
and broadcast search outstanding (3080). At other times, all the searches that are sent and their results 
are supplied in the search failure (8130) session setup state. 


Table 5. Search-Sent Information Elements 


Byte Hex Value | Content 
Header Information for Variable Data 
Length of this type of variable data 
X'01' Key value for a search-sent element 
Variable Data 

3 Network identifier of the system searched 
0B Control-point name of the system searched 
13 Search type 

X'00' No search sent 

X'01' Search type is single hop 

x'02' Search type is directed to a network node control point 

X'03' Domain broadcast 

x'04' Network broadcast 

X'05' Directed for remote search 

X'06' Directed to a node that can access multiple networks 
14 Node type 

X'01' End node 

X'02' Network node 

X'03' Control point resides in a network with a different network identifier 
15 Search results 

X'00' Search response not received 

X'01' Positive explicit response 

X'02' Positive *~ANY response 

X'03' Negative response 
16 Sense code 


Regular Route Selection Control Vector (RSCV) 46 
The regular structure is used for an RSCV consisting of X'46' control vectors. It is used in BIND 
processing. 
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The route selection control vector (RSCV) is carried in BIND, RSP(BIND), and other RUs. It describes the 
path through an APPN network that a session is to take or has taken. The RSCV is sent and received by 
APPN nodes, but not by LEN nodes. 


Table 6. Routing Information RSCV 46 


Byte Hex Value | Content 
Header Information for Variable Data 
0 Length of this type of variable data 
2 X'02' Key value for routing information (RSCV 46) variable data 
Variable Data 
3 RSCV length 
4 RSCV key = X'2B' 
Maximum hop count: the binary number of the transmission group descriptor or 
5 network name. 


Current hop count: the binary index number of the last transmission group 
6 descriptor control vector. 


7-n Control vectors 


Transmission group descriptor control vector: one for each transmission group on 
X'46' the session path (present when the RSCV is carried on a BIND or RSP(BIND)). 


Regular Route Selection Control Vector (RSCV) 0E 
The regular structure is used for an RSCV consisting of X'OE' control vectors. It is used in search 


processing. 


This route selection control vector (RSCV) is carried in search requests through an APPN network. APPN 
network nodes send and receive the RSCV. 


Table 7. Routing Information RSCV OE 


Byte Hex Value | Content 
Header Information for Variable Data 
0 Length of this type of variable data 
2 X'03' Key value for routing information (RSCV OE) variable data 
Variable Data 

3 RSCV length 
4 RSCV key = X'2B' 

Maximum hop count: the binary number of the transmission group descriptor or 
5 network name. 

Current hop count: the binary index number of the last transmission group 
6 descriptor control vector. 
7-n Control vectors 

X'0E' Control-point name control vector: one for each control point on the search path 


Single Hop Route Failure Element 

This structure consists of the partner node for the single-hop-route request and an array of 255 entries that 
represent the status of particular transmission groups. The single hop route element explains why the 
entries could not be used. 
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Table 8. Single Hop Route Information 


Byte 


Bits 


Content 


Header Information for Variable Data 


Length of this type of variable data 


X'04' 


Key value for routing information variable data 


Variable Data 


Network identifier of the partner node 


Control-point name of partner node 


The 255 entries (1 byte each) that represent the state of the transmission group 


X'00' 


Transmission group number not defined 


X'01' 


Transmission group is active but does not have the correct class-of-service 
characteristics 


X'02" 


Transmission group is inactive but does have correct class-of-service 
characteristics 


X'03' 


Transmission group is inactive and does not have correct class-of-service 
characteristics 


Ineligible Destination Network Nodes Elements 
This structure specifies the reason why a particular transmission group returned by an end node is 


ineligible for providing access to the APPN network. 


Note: There may be multiple elements supplied. The header information length should be used to 


determine when all elements have been processed. This information may be available for state 


Table 9. No Destination Network Nodes Eligible Information 


Byte 


Hex Value 


Content 


Header Information for Variable Data 


X'05' 


Length of this type of variable data 


Key value for routing information variable data 


Variable Data 


Network identifier of the ineligible destination network node 


Control-point name of the ineligible destination network node 


13 


Transmission group number of ineligible destination node 


14 


Reason why transmission group is ineligible 


X'00' 


Transmission group number not defined 


X'01' 


Transmission group is active but does not have the correct class-of-service 
characteristics 


X'02' 


Transmission group is inactive but does have correct class-of-service 
characteristics 


X'03' 


Transmission group is inactive and does not have correct class-of-service 
characteristics 


Destination Node List 
This structure contains a single network-qualified control point name that represents one of the possible 
destinations (network nodes or virtual nodes) that, during route selection, could not reach. 
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Note: There may be multiple elements supplied. The header information length should be used to 
determine when all elements have been processed. This information may be available for states 
4062, 4064, 4066, and 4068. 


Table 10. Destination Node List 
Byte Hex Value | Content 


Header Information for Variable Data 


Length of this type of variable data 


X'06' Key value for routing information variable data 


Variable Data 


3 Network identifier of the destination node 


Control-point name of destination node 


13 Node type 
x'02' Network node 
x'04' Virtual node 


User Class-of-Service with Inactive Transmission Groups RSCV 
This structure is used to represent an RSCV that allows inactive transmission groups. It has the same 
class-of-service characteristics as the class-of-service that is given by the user. 


BIND, RSP(BIND), and other RUs carry the route selection control vector (RSCV) . It describes the path 
through an APPN network that a session is to take or has taken. APPN nodes send and receive the RSCV 
, but LEN nodes do not. 


Table 11. User Class-of-Service with Inactive Transmission Groups 


Byte Hex Value | Content 


Header Information for Variable Data 


Length of this type of variable data 


X'07' Key value for routing information variable data 


Variable Data 


3-4 RSCV length 
RSCV key = X'2B' 


Maximum hop count: the binary number of the transmission group descriptor or 


6 network name 

Current hop count: the binary index number of transmission group the last 
7 descriptor control vector 
8-n Control vectors 


Transmission group descriptor control vector: one for each transmission group on 
X'46' the session path 


Transmission group characteristics of control vector: one for each transmission 
group on the session path (present when the RSCV is carried on a BIND or 
X'47' RSP(BIND)) 


Any Class-of-Service with Active Transmission Groups RSCV 
This structure represents an RSCV that allows active transmission groups, but allows any class-of-service 
characteristics to be acceptable. 
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BIND, RSP(BIND), and other RUs carry the route selection control vector (RSCV) . It describes the path 
through an APPN network that a session is to take or has taken. APPN nodes send and receive the RSCV 


, but LEN nodes do not. 


Table 12. User Class-of-Service with Active Transmission Groups 


Byte Hex Value 


Content 


Header Information for Variable Data 


Length of this type of variable data 


X'08' 


Key value for routing information variable data 


Variable Data 
RSCV length 


RSCV key = X'2B' 


Maximum hop count: the binary number of the transmission group descriptor or 
network name 


Current hop count: the binary index number of the last transmission group 
descriptor control vector 


X'46' 


Control vectors 


Transmission group descriptor control vector: one for each transmission group on 
the session path 


X'47' 


Transmission group characteristics control vector: one for each transmission 
group on the session path (present when the RSCV is carried on a BIND or 
RSP(BIND)) 


110 = iSeries: Networking APPC, APPN, and HPR 


Printed in U.S.A. 


